0

Ich habe eine Anforderung, wo ich eine Datenbank erstellen muss, wo ein Benutzer mehrere Zahlungsmethoden haben kann und gegen diese mehrere Zahlungsmethoden mehrere Transaktionen verarbeitet werden können.Integration von Zahlungsmethoden in DB-Schemas

Ich habe das folgende Schema erstellt

enter image description here

WARUM DIESE TABELLEN:

Benutzer: Diese Tabelle enthält Informationen über den Benutzer enthält. Ex: Vorname, Nachname, E-Mail usw.

user_payment_method: Da ein einzelner Benutzer mehr Zahlungsmethoden haben kann ich eine Tabelle erstellt alle Methoden, um die Zahlung zu identifizieren, die er so hat, dass ich sie in der Tabelle Buchungen verweisen kann und könnte genau wissen, auf welcher Zahlungsmethode die Transaktion durchgeführt wurde.

Transaktion: Diese Tabelle enthält alle Daten zu allen Transaktionen. Bsp .: Zeit, Benutzer_ID, Benutzer_Method_ID, Betrag usw.

payment_method: Diese Tabelle fungiert als eine Junction-Tabelle (Pivot-Tabelle), um alle Zahlungsmethoden zu referenzieren, die existieren könnten. Da alle Zahlungsmethoden unterschiedliche Details haben, kann ich dafür keine einzige Tabelle erstellen.

spezifische Zahlungsmethode Tabellen: Tabellen wie bank_transfer und paypal enthalten die spezifischen Details, die der Benutzer über diese Zahlungsmethode hat. Ex: paypal Schlüssel oder Bankkontonummern

DAS PROBLEM

Ich stecke in einer Beziehung zwischen payment_method und specific payment method tables zu schaffen.

Wie referenziere ich verschiedene Zahlungsmethoden innerhalb einer einzelnen Spalte in der Tabelle payment_method. Erstelle ich für jede bestimmte Zahlungsmethode eine Junction (Pivot) -Tabelle?

EDIT: Wenn jemand einen einfacheren anderen Ansatz hat auch mich bitte wissen lassen, bin ich für alle Ideen offen.

Antwort

1

Das Problem als Modellierung Vererbung kategorisiert werden können. Sie haben n Zahlungsmethoden mit jeweils unterschiedlichen (benutzerspezifischen) Eigenschaften. Die einfachste TPH-Tabelle pro Hierarchie: Legen Sie alle Benutzereigenschaften für alle Zahlungsmethoden in die Tabelle user_payment_method ein. Es gibt andere Optionen, die abgedeckt werden here. Vergessen Sie die Pivot-Tabelle: Sie modellieren ein DB-Schema und Sie benötigen nur Tabellen und Spalten. Denken Sie darüber nach, was Sie speichern müssen, wie Sie es abrufen müssen und wie wichtig es ist, jede Tatsache nur einmal zu speichern.

+0

Sie sagen also, dass für jeden Datensatz in der Tabelle der Zahlungsmethoden einige Zeilen leer bleiben. Wenn die Methode user_payment_method für paypal ist, werden die Bankdaten leer gelassen und es wird eine Spalte geben, die angibt, um welche Art von Zahlungsmethode es sich handelt. Okay also, wenn der Benutzer in Zukunft entscheidet, eine weitere Zahlungsmethode hinzuzufügen. Wie wenn er Banküberweisung hat und er auch paypal hinzufügen möchte, wird eine neue Reihe dafür geschaffen? –

+0

@FahadSohail In einer Datenbank gibt es keine leeren Zeilen. Ich denke du meinst Säulen? Wenn dies der Fall ist, dann werden einige Zeilen in den Zeilen fehlen, abhängig von der Art der Daten für jede Zahlungsart. Das ist keine perfekte Lösung, aber es ist relativ einfach. Eine bessere Lösung wären zusätzliche Tabellen in einer Eins-Eins-Beziehung, aber das erfordert mehr Verständnis und kann später bearbeitet werden. – Manngo

+0

Yup das ist es. Leere Zellen in einer Tabelle sind kein Problem und in der Praxis sehr häufig. Die Lösung, die Manngo vorschlägt, ist TPCC Tisch-pro-Beton-Klasse. Sobald Sie den Namen des Problems kennen, mit dem Sie es zu tun haben, können Sie schnell [Unmengen an Material] finden (http://blog.devart.com/table-per-type-vs-table-per-hierarchy-inheritance. html) über Vor- und Nachteile. – bbsimonbb

2

würde ich wahrscheinlich das Schema vereinfachen, wie folgt:

user <- transaction -> payment method 

Die Zahlungsart Ihre PayPal und Banküberweisung umfassen würde, die nicht verschiedene Tabellen sein sollte.

Im Allgemeinen sollten Sie Ihre Zahlungsmethode als Typ der Transaktion denken.

Beim Erstellen einer Datenbank suchen Sie nach den Tabellen, in denen die eigentliche Aktion ausgeführt wird. In diesem Fall ist es die Transaktionstabelle. Sie können es aus einem Entitätsdiagramm als das mit den nach außen zeigenden Fremdschlüsseln erkennen.In diesem Fall können Sie sagen, dass eine Transaktion zu einem Benutzer gehört und einem bestimmten Typ angehört.

Die Transaktionstabelle würde die tatsächlichen Zahlungsdaten, wie Datum, Betrag, Transaktionsnummer usw.

Sie auch eine Tabelle von bevorzugten Zahlungsdetails haben könnte. Das würde Ihnen etwas wie folgt aus:

user  <- transaction -> payment method 
      <- preferred -> 

Denken Sie daran, dass die Präferenzen ändern können, so dass die Daten aus der bevorzugten Tabelle sollte in die Transaktionstabelle kopiert werden, zu ermöglichen, die Präferenzen später zu ändern.

Unnötig zu sagen, wir gehen davon aus, dass Sie alle entsprechenden Vorsichtsmaßnahmen in Bezug auf Passwörter nehmen, Kontodaten und andere sensible Daten ...

Verwandte Themen