Betrachten Sie ein Modell für den Abgleich von Clients und Services. Kunden können zu verschiedenen Zeiten sowohl Anbieter als auch Abnehmer von Diensten sein. Kunden können Einzelpersonen oder Gruppen (Firmen) sein, wobei letztere mehrere Kontakte haben. Kontakte können mehrere Adressen, Telefone, E-Mails haben. Einige dieser Beziehungen werden Eins-zu-eins sein (z. B. Dienst für Anbieter), aber die meisten werden Eins-zu-Viele oder Viele-zu-Viele sein (mehrere Kontakte in einem Unternehmen haben die gleiche Adresse).
In diesem Modell würden typischerweise mehrere assoziative Tabellen existieren, z. B. client_contact, contract_addr, contact_phone, contact_email, service_provider, service_consumer, etc.
Angenommen, Sie geben eine einfache Abfrage für Kontaktinformationen für Kunden eines bestimmten Dienstes aus. Zusätzlich zu den sechs Entitätstabellen, die die Daten enthalten, verweisen die Joins auf fünf assoziative Tabellen. Nichts über diese Art von Abfrage ist natürlich besonders interessant - wir machen es jeden Tag.
Es ist mir aber aufgefallen: Warum nicht eine einzige assoziative "Master" -Tabelle haben, die alle Assoziationen enthält? Es würde erfordern, dass diese Haupttabelle einen "Zuordnungstyp" zusätzlich zu den zwei PKs aufweist und dass alle PKs vom gleichen Typ sind (Ints, GUIDs, etc.).
Auf der einen Seite würden Abfragen komplizierter, weil jeder Join den Typ und PK spezifizieren müsste. Auf der anderen Seite würden alle Joins auf die gleiche Tabelle zugreifen und bei entsprechender Indicnng- und Caching-Performance könnten sie sich dramatisch verbessern.
Ich nahm an, dass es ein Muster (oder Anti-Muster) geben könnte, das diesen Ansatz beschreibt, aber nichts online gefunden hat. Hat jemand es versucht? Wenn ja, skaliert es?
Alle Referenzen, die Sie zur Verfügung stellen können, wären willkommen.
Was Sie beschreiben, erinnert mich an Faktentabellen aus Data Warehousing. Mein Verständnis ist, dass Sie mit einem typischen Transaktionsschema mit einer Tabelle beginnen, um jede Viele-zu-Viele-Beziehung zu modellieren. Um die Daten für eine einfachere Dimensionsanalyse neu zu strukturieren, können Sie einige / alle Beziehungen in Ihrem Schema in einer großen Tabelle aggregieren, wobei jede Spalte ein Schlüssel ist. Dadurch werden alle möglichen Verknüpfungen vorzeitig ausgeführt und in einer Tabelle gespeichert. Dadurch wird der Zweck von Abfrageverbindungen von der Beziehungsverfolgung in die Eigenschaften Ihrer Entitäten umgewandelt.
Wie auch immer, mein Verständnis dieser Dinge ist verschwommen und meine Erfahrung ist praktisch gleich Null, aber vielleicht ist Ihre Idee eine Faktentabelle mit einem anderen Namen, was sie für die Untersuchung nützlich macht.
Zunächst einmal denke ich, dass Sie definitiv einen Preis für Wartbarkeit bezahlen. Jedes Mal, wenn ich eine solche Spalte habe, denke ich an die rote Flagge. Es scheint wahrscheinlich, dass es zu magischen Strings in Ihren Prozeduren kommt - Sie müssen sicherstellen, dass der Typ über Inserts und Selects konsistent ist, z. Daher muss jede Leistungssteigerung groß genug sein, um diese Kopfschmerzen zu rechtfertigen.
Zweitens zahlen Sie einen Preis, wenn Sie mehr Daten speichern - die zusätzliche Spalte "Typ" für jede Zuordnung. Und dann müssen diese Daten abgerufen werden, wenn eine Abfrage ausgeführt wird, die sich darauf auswirkt, wie viele Zeilen gleichzeitig (möglicherweise) im Speicher vorhanden sein können.
Drittens muss jede Abfrage wahrscheinlich auf die gleiche Gesamtanzahl von Zeilen zugreifen, unabhängig davon, ob sie in mehreren Tabellen oder in einer Tabelle gespeichert sind. Wenn Sie also nichts über Ihre Daten wissen, mit denen Sie Clustered-Indizes erstellen können, erhalten Sie beim Ausführen von Abfragen wahrscheinlich die gleiche Anzahl an Seiten.
Viertens, die wahrscheinlichen Leistungsgewinne kommen von der Annahme, dass der Index ein logarithmisches Verhalten hat, und dass 5log (N) größer ist als log (5N), also ist es besser, einen großen Index als 5 kleinere zu verwenden. Die Hinzufügung der Typspalte wird diesen Vorteil jedoch reduzieren. Ich bin nicht wirklich sicher, wie man analysiert, ob es es vollständig beseitigen oder es nur reduzieren würde.
Fünftens scheint es ziemlich wahrscheinlich, dass Sie bei einigen Anfragen am Ende mehrere Kopien dieser riesigen Tabelle beitreten werden, was wirklich so aussieht, als würde es ein Mörder werden.
Es würde mich interessieren, welche Ergebnisse Sie erhalten, aber ich wäre überrascht, wenn es einen Leistungsvorteil geben würde.
Dies kann mit Abstraktion und Tabellenvererbung gelöst werden.
Ein einzelner Kunde, Organisationskunde, Dienstleister sind alle Parteien, die Rollen spielen.
Eine E-Mail-Adresse, Telefonnummer, Webadresse und physische Adresse sind alle Adressen.
Tags und Links design-patterns database-design anti-patterns associative-table