Erstellen Sie eine Tabelle, um gemeinsam genutzte Attribute zwischen Tabellen zu speichern, wie Sie mit Composite Keys umgehen?

Question

Ich suche eine Datenbank-Lösung für den Umgang mit Szenario wie folgt:

Eine Menge Tabellen: TableA, TableB, TableC ... teilen einige Attribute (Felder), möchte ich diese gemeinsamen Attribute in einer Tabelle speichern , nennen wir es Shared Table. wie folgt aus:

TableA: 
| KeyA | Shared Attr.1 | ... | Other Attr. | 
| A_1 | A_SValueA1  | ... | A_OValueA1 | 

TableB: 
| KeyB | Shared Attr.1 | ... | Other Attr. | 
| B_1 | B_SValueA1  | ... | B_OValueA1 | 

Shared Table: 
| KeyShare | EntityType | Shared Attr.1 | ... | 
| A_1  | A   | A_SValueA1  | ... | 
| B_1  | B   | B_SValueA1  | ... | 

Natürlich werde ich eine Tabelle erstellen für jede Tabelle bestimmte Attribute zu speichern.

Aber ich brauche dieses Problem zu lösen, Tabelle C, die ich auch seine gemeinsame Attribute in SharedTable speichern möchten, hat zusammengesetzte Schlüssel, wie folgt aus:

TableC: 
| KeyC1 | KeyC2 | Shared Attr.1 | ... | Other Attr. | 
| C1_1 | C1_2 | C_SValueA1  | ... | C_OValueA1 | 

So kann ich nicht nur damit umgehen wie TableA und TableB. Gibt es ein gutes Design, um Composite-Tasten in Tabelle wie C zu behandeln? Ich bin mir sicher, dass das nicht ein paar neue Fragen sind, viele Leute haben vielleicht konfrontiert und es gelöst, aber ich habe viel gesucht und konnte keine vorhandenen Fragen finden.

---

In der Tat ist dieses Szenario als Alternative von EAV Antipattern entwickelt, weil TableA/B/C der gleichen Klasse sind, so haben sie Attribute geteilt, und sie wirken als Unterklasse, so dass sie spezielle Attribute .

In Klassenebene sind sie die gleichen Dinge, sie können verglichen, sortiert, berechnet werden, so dass sie in einer Tabelle platziert werden können.

Answer 1

Ich stimme hier ganz zu @Damien_The_Unbeliever. Das klingt wirklich sehr nach OTLT.

Aggregieren von Daten aus TableA und TableB kann durch Vererbung erreicht werden:

CREATE TableA INHERITS SharedTabele; 
CREATE TableB INHERITS SharedTabele; 

oder die Verwendung einer Ansicht:

CREATE VIEW SharedTable AS 
SELECT * FROM TableA 
UNION ALL 
SELECT * FROM TableB 

Aber wenn man erklärt Sie eine radikal andere TableC zu schieben versuchen, in Am selben gemeinsamen Tisch wurde mir klar, dass etwas nicht stimmt. Dies ist schwer zu tun, weil es nicht viel Sinn macht.

Bitte denken Sie darüber nach, Ihren Ansatz zu ändern. OTLT wird nichts lösen und es wird definitiv die Dinge komplizierter machen.

Answer 2

Wenn Sie wirklich wollen, dass diese (und ich stimme mit der anderen Antwort, dass dies eine schlechte [tm] Idee ist) - drehen Sie die Lösung upside-down:

Sie den Schlüssel zu der bestimmten Einheit nicht speichern in die gemeinsame Tabelle, speichern Sie einen Verweis auf eine neue "Shared Entity" in Ihrer bestimmten Tabelle.

Zum Beispiel:

CREATE TABLE TableA (
    id INT PRIMARY KEY, 
    my_special_attr VARCHAR, 
    shared_attr_set INT REFERENCES Shared(attr_set_id) 
); 
CREATE TABLE TableC (
    id1 INT, 
    id2 VARCHAR(2), 
    my_special_attr VARCHAR, 
    shared_attr_set INT REFERENCES Shared(attr_set_id), 
    PRIMARY KEY (id1, id2) 
); 
CREATE TABLE Shared (
    id INT PRIMARY KEY, 
    attr_set_id INT, 
    shared_attr_1 INT, 
    shared_attr_2 VARCHAR 
); 

Natürlich bedeutet dies, Sie nach sich selbst zu bereinigen haben werden, wenn Sie Instanzen von bestimmten Klassen entfernen - müssen Sie entweder Shared für „verwaiste“ Sätze scannen oder löschen zusammen mit der Instanz.

Lassen Sie mich mit einem Wort der Warnung enden: Ich war dort. Ich vermasselte. Dies ist ein Rezept für eine Los Kopfschmerzen.Ziehen Sie in Betracht, Shared eine vollständige Entität zu erstellen und composition over inheritance zu verwenden.

Answer 3

zu verstehen, dass es eine Alternative zu EAV anti pattern ist, wenn Sie es wirklich funktionieren lassen möchten, vielleicht können Sie einen einzelnen Primärschlüssel für Ihre Tabelle verwenden C: Hinzufügen einer neuen Autoinkrementspalte, die als primary gesetzt wird Schlüssel und belassen Sie Ihre zusammengesetzten Schlüsselspalten so, wie sie sind, aber fügen Sie eine eindeutige Einschränkung für sie hinzu.

Dies würde das Problem in der gemeinsamen Tabelle beheben. obwohl Abfrage möglicherweise Kopfschmerzen später ...

ein anderer Ansatz, den ich schon gesehen habe, ist, dass eine Elterntabelle verwendet, die die Schlüssel und gemeinsame Spalten enthält, während Kinder die Tabelle erweitern, um bestimmte Spalten zu haben. Beispiel:

TableParent: 
| Key | Type | Shared Attr.1 | Shared Attr.2 |... | Other common Attr. | 
| P_1 | A | Value A1  | Value A2  |... |     | 
| P_2 | B | Value B1  | Value B2  |... |     | 
| P_3 | C | Value C1  | Value C2  |... |     | 
Key column is auto-incremental primary key column 

TableChildA: 
| Key | Col1 | Col2 | ... | 
| P_1 | Val 1| Val 2 | ... | 
The Key column is not auto-incremental, but foreign-keyed back to TableParent Key column 

TableChildB: 
| Key | Col3 | Col4 | ... | 
| P_2 | Val 3| Val 4 | ... | 
The Key column is not auto-incremental, but foreign-keyed back to TableParent Key column 

TableChildC: 
| Key | Composite Key 1 | Composite Key 2 |Col5 | Col6 | ... | 
| P_3 | key 1   | Key 2   |Val 5| Val 6 | ... | 
The Key column is not auto-incremental, but foreign-keyed back to TableParent Key column 
Also there is a unique constraint on Composite Key 1 + Composite Key 2 

wahrsten Sinne des Wortes in Ihrem Code, können Sie übergeordnete Klasse von TableParent wenn er eine eigene Kinder-Klasse für TableA/B/C ...