Schemadesign für die Verarbeitung mehrerer Zahlungsgateways

Dies ist eher eine Frage, die Feedback erfordert. Ich entwerfe eine Datenbank, die mehrere Zahlungsgateways verwaltet. Ein Zahlungsgateway benötigt meistens eine Tabelle mit Bestelldetails vor der Zahlung (dies gilt für alle PGs) und eine Tabelle mit Transaktionsdetails, um die Antwort nach der Zahlung zu speichern.

Um nun mehrere Zahlungsgateways zu verarbeiten, kann ich entweder eine einzelne Transaktionstabelle führen und sie mit allen Feldern füllen, die von allen Zahlungsgateways verfügbar sind, sowie mit einem Feld, aus dem hervorgeht, von welchem PG diese Zeile stammt.
Oder ich kann separate Transaktionstabellen für jedes PG mit dem Präfix like paypal_oder bank_etc erstellen , wobei jedes die Felder enthält, die jedes von ihnen benötigt.

Ich bin mir nur nicht sicher, welcher Weg der optimalere ist. Ich muss es auch für ähnliche Szenarien lernen, auf die ich in Zukunft stoßen könnte.

database-design

— Bibhas
quelle

Es hängt von Ihrer genauen Situation ab. Im Allgemeinen ist es billiger, Teilmengen einer großen Tabelle auszuwählen, als viele kleine winzige Tabellen mit UNION zusammenzuführen. Es gibt jedoch Situationen, in denen das Design winziger Tische besser funktioniert.

— Walter Mitty

Was hast du bisher?

— Aaron

@ BryceAtNetwork23 Im Moment verarbeite ich zwei PGs und habe für beide separate Tabellen. Aber ich muss in Zukunft weitere PGs hinzufügen. Also überlegte ich, ob ich das weiter machen sollte, da ich jedes Mal mehr Tabellen hinzufügen muss. Sie können zwischen einer zunehmenden Anzahl von Tabellen und einer Tabelle mit zunehmender Anzahl von Spalten und Datensätzen wählen. Ich bin ein bisschen verwirrt.

— Bibhas

@Bibhas, ist es möglich, uns die von Ihnen verwendete Lösung mitzuteilen? Ich habe den gleichen Zweifel.

— Marcio Mazzucato

@MarcioSimao wir mit einzelnen Tabelle mit Eigenschaften wie ging paypal_transaction_id, bank_transaction_idusw. hatten wir nicht zu viele Zahlungs - Gateways, so dass es für uns gearbeitet. Funktioniert möglicherweise nicht mit denen, die viele PGs unterstützen.

— Bibhas

Dies hängt davon ab, wie unterschiedlich die Daten zwischen den Zahlungsarten sind.

Für die Websites, die ich bei der Arbeit unterstütze, haben wir eine Tabelle, in der Daten für alle Zahlungsarten gespeichert sind. Das funktioniert bei uns, da unsere Zahlungsarten im Grunde 4 Arten von Kreditkarten und Unternehmensbestellungen sind. Die meisten unserer Kunden zahlen mit Kreditkarten, daher gibt es keine großen Abweichungen in den Daten. Abfragen für diese Kreditkartenkunden ergeben natürlich immer NULL-Werte im Feld PONumber. Ebenso ergeben Anfragen an PO-Kunden NULL-Werte in allen kreditkartenbezogenen Feldern.

Wenn Ihre Daten viele verschiedene Felder enthalten, können Sie eine Haupttransaktionstabelle mit individuellen Tabellen für jedes Zahlungsgateway ausprobieren. Jede Tabelle mit Zahlungsgateway-Typ hätte einen Fremdschlüssel von transaction_id, der mit der Haupttransaktionstabelle verknüpft wäre.

Wenn andererseits Ihre Zahlungsgateway-Typen alle ähnliche Felder haben, würde ich mich an eine Transaktionstabelle halten.

— Aaron
quelle

Danke, dass du das geklärt hast. Ich denke, es war direkt vor mir, aber ich brauchte nur jemanden, der darauf hinweist. :)

— Bibhas

@ BryceAtNetwork23, Wenn ich viele Gateways habe, wie z. B. 5 oder mehr, denke ich, dass ich Schwierigkeiten haben werde, die Daten zu erhalten? Ich frage dies, weil ich denke, dass die Haupttransaktionstabelle viele Linksverknüpfungen in jedem Zahlungsgateway-Typ ausführen muss.

— Marcio Mazzucato