Wir haben ein SQL Server DB-Entwurfszeitszenario. Wir müssen Daten zu verschiedenen Organisationen in unserer Datenbank speichern (z. B. Kunde, Lieferant, Händler, ...). Alle Diff-Organisationen haben (fast) die gleiche Art von Informationen wie Adressdetails usw. Und sie werden in anderen Tabellen referenziert (d. H. Über OrgId verknüpft, und wir müssen OrgName an vielen Diff-Stellen nachschlagen).

Ich sehe zwei Möglichkeiten:

Wir erstellen eine Tabelle für jede Organisation wie OrgCustomer, OrgDistributor, OrgVendor usw. Alle Tabellen haben eine ähnliche Struktur und einige Tabellen haben zusätzliche Spezialfelder, wie der Kunde ein Feld HomeAddress (das die anderen Org-Tabellen nicht haben) ) .. und umgekehrt.

Wir erstellen eine gemeinsame OrgMaster-Tabelle und speichern ALLE Diff-Orgs an einem einzigen Ort. Die Tabelle enthält ein OrgType-Feld zur Unterscheidung der Diff-Typen von Orgs. Und die speziellen Felder werden an die OrgMaster-Tabelle angehängt (nur relevante Org-Datensätze haben Werte in solchen Feldern, in anderen Fällen ist es NULL).

Einige Vor- und Nachteile von # 1:

PROS:

Es hilft, die Last zu verteilen, während auf verschiedene Arten von Org-Daten zugegriffen wird, daher glaube ich, dass dies die Leistung verbessert.Bietet einen vollständigen Bereich zum Anpassen einer bestimmten Organisationstabelle, ohne die anderen vorhandenen Organisationstypen zu beeinflussen.Ich bin mir nicht sicher, ob Diff-Indizes für Diff / Distributed-Tabellen besser funktionieren als eine einzelne große Tabelle.

Nachteile:

Replikation des Designs. Wenn ich das ZipCode-Feld vergrößern muss, muss ich das in ALLEN Tabellen tun.Replikation in der Manipulationsimplementierung (d. H. Wir haben gespeicherte Prozeduren für CRUD-Operationen verwendet, sodass die Replikation n-fach verläuft. 3-4 inerte SPs, 2-3 SELECT SPs usw.)Von den DB-Einschränkungen \ Indizierung auf SP bis zu den Business-Objekten im Anwendungscode wächst alles n-fach.Eine (gemeinsame) Änderung an einem Ort muss auch an allen anderen Orten vorgenommen werden.Einige Vor- und Nachteile von # 2:

PROS:

N-fach wird 1-fach :-)Die Wartung wird einfach, da wir versuchen können, einzelne Einstiegspunkte für alle Vorgänge zu implementieren (d. H. Einen einzelnen SP für CRUD-Vorgänge usw.).Wir müssen uns darum kümmern, eine einzige Tabelle zu pflegen. Die Indizierung und andere Optimierungen sind auf eine einzelne Tabelle beschränkt.

Nachteile:

Erzeugt es einen Engpass? Kann es verwaltet werden, indem Views und andere optimierte Datenzugriffsstrategien implementiert werden?Die andere Seite der zentralisierten Implementierung ist, dass eine einzelne Änderung an ALLEN Stellen getestet und verifiziert werden muss. Es ist nicht abstrakt.Das Design scheint etwas weniger 'organisiert \ strukturiert' zu sein. aufgrund der wenigen Orgs, für die wir 'spezielle' Felder hinzufügen müssen (die für die anderen Tabellen irrelevant sind)

Ich habe mir auch eine Option # 3 überlegt - die Org-Tabellen getrennt halten, aber eine gemeinsame OrgAddress-Tabelle erstellen, um die gemeinsamen Felder zu speichern. Aber das versetzt mich in die Mitte von # 1 & # 2 und sorgt für noch mehr Verwirrung!

Um ehrlich zu sein, ich bin ein erfahrener Programmierer, aber kein ebenso erfahrener DBA, da dies nicht meine Hauptaufgabe ist. Bitte helfen Sie mir, den richtigen Kompromiss zwischen Parametern wie Designkomplexität und Leistung zu finden.

Danke im Voraus. Für technische Fragen und Anregungen stehen wir Ihnen gerne zur Verfügung.

Hemant