Frage zum Datenbankentwurf (FK zu verschiedenen Tabellen)

Question

Betrachten Sie einen Einkaufswagen, der es Kunden ermöglicht, variable Bezahlsysteme zu verwenden.

Jedes System hat einen anderen Satz von Parametern: System A hat Attribute wie Referenz-ID, XML-Antwort, Transaktions-ID, System B hat Transaktions-ID und Status, System C (Scheck) hat nur Zahlungsdatum. Die Zustände unterscheiden sich auch in jedem System.

Auf der Zahlungssystem-Auswahlseite befinden sich Name und Beschreibung des Zahlungssystems, die ebenfalls in der Datenbank gespeichert werden sollen (z. B. nicht HTML-codiert).

Wie würden Sie die Datenbank entwerfen?

Das Beste, was ich mir vorstellen kann, ist eine Tabelle für jedes System + eine Tabelle für Zahlungssystembeschreibungen, die mit dem Namen der relevanten Tabelle verknüpft sind + 2 zusätzliche Felder in der Auftragstabelle: Zahlungssystem-ID (wird verknüpft mit " Beschreibungstabelle "), Zahlungsaufzeichnungs-ID (wird mit der ID in der entsprechenden Zahlungssystemtabelle verknüpft). Dies würde auch ermöglichen, spezifische Funktionalität (Auftragsbenachrichtigungsverarbeitung usw.) bereitzustellen, die zwischen Zahlungssystemmodellen getrennt werden soll, anstatt if s zu verwenden. Ist es o.k?

Wenn überhaupt, basiert das Projekt auf PHP 5, Doctrine und MySQL.

Answer 1

Diskutierbar könnten Sie eine Hauptsystemtabelle, die jede gemeinsame Information enthält (eine ID, einen Namen, was auch immer) und dann eine zweite Tabelle, die Name/Wert-Paare für die Attribute sammelt:

CREATE TABLE system_table 
(id int, 
name char(50), 
... 
); 

CREATE TABLE system_properties 
(system_id int, 
name char(50), 
value varchar 
); 

Dies könnte für die Leute wegen der unscharfen Zuordnung von Eigenschaften unattraktiv sein, aber auf der anderen Seite wird das Erhalten der Eigenschaften für jedes System eine einfache Verbindung, anstatt zu versuchen, eine Handvoll Tabellen zusammen zu ziehen.

Bitte beachten Sie, dass die obigen SQL create-Anweisungen Pseudocode-ish sind.

Answer 2

Eine Tabelle für jeden Typ des Zahlungssystems - der Typ ist ein eindeutiger Satz von Attributen, die einem oder mehreren Zahlungssystemen gemeinsam sind. Haben Sie eine übergeordnete Tabelle aller Typen, die Attribute enthalten, die von allen gemeinsam verwendet werden (z. B. der Systemname).

Answer 3

Was dportas und jaydel sagten, plus meine zwei cents.

Jedes Zahlungssystem sollte in einer Tabellenzeile stehen, nicht in einer eigenen Tabelle. Jede Art von Zahlungssystem (spezielles Zahlungssystem) benötigt eine eigene Tabelle für Daten, die nur für diesen Typ gesammelt werden.

Darüber hinaus sollte es eine generische Zahlungssystemtabelle geben, die Daten für alle Arten von Zahlungssystemen enthält.

Die Beziehung zwischen der allgemeinen Zahlungssystemtabelle und den spezialisierten Zahlungssystemtabellen ist ein klassisches "gen = spec desing pattern". Wenn Sie nach "relationale Modellierung der Generalisierungsspezialisierung" suchen, finden Sie Artikel, die Ihnen beibringen, wie Sie relationale Tabellen für das Gen-Spec-Muster entwerfen.

Die kurze Antwort ist, dass die Gen-Tabelle ein klassisches ID-Feld hat, das als PK fungiert. Jede spezialisierte Tabelle hat ein ID-Feld, das ein Duplikat des ID-Felds in der Gen-Tabelle ist. Dies bedeutet, dass es sowohl ein PK im spezialisierten Feld als auch ein FK ist, der auf die Gen-Tabelle verweist.

FK-Verweise auf ein Zahlungssystem an einer anderen Stelle in der Datenbank sollten auf die gen-Tabelle verweisen.