Frage zum Datenbankentwurf

Wenn Sie Joels Rat in Betracht ziehen, gehen Sie bitte hier .

oder hier

oder hier

Und wenn du keinem von ihnen glaubst, baue die 4 Tische auf, die er erwähnt. Es gibt nur 4, dauert nicht lange. Dann laden Sie einige Daten in sie ... dann versuchen Sie, die Abfragen zu schreiben, die Sie schreiben möchten ...

Ändern der Spaltenbedeutung:

Dies kann wirklich mit Kardinalitätsschätzungen verschrauben. Ihre Teller liegen zwischen 4 - 20, die Konzertsitze zwischen 1000 - 2000. Einige Kardinalitätsberechnungen betrachten die Verteilung von Min bis Max und gehen von einer gleichmäßigen Verteilung aus (wenn andere Statistiken fehlen) ...

Von 4 bis 2000 bedeutet das, dass GENERIC_COLUMN = n,% der Zeilen, die Sie treffen, 1 / 1996. ist, aber wenn Sie sagen, wo EVNT_TYPE = Dinner und GENERIC_COLUMN = n wäre, wäre es WIRKLICH zwischen 4 und 20, oder 1/16 der gesamten Reihen ... so ein großer Schwung in der Kartenschätzung. (Dies kann mit Histogrammen behoben werden, aber der Punkt, der die Automatisierungsprobleme zeigt, ist nur, um zu verdeutlichen, dass es, wenn es sich um ein Problem handelt, wahrscheinlich nicht so sauber ist, wie es sein könnte.)

Also, wenn Sie das tun würden (viel besser als ein EAV, aber ...)

Ich würde empfehlen, für jedes Objekt eine Ansicht zu erstellen.

Table EVENT (gemeinsame Felder, Generic_Count) Anzeigen DINNER (allgemeine Felder, Generic_Count als Platten) WHERE Typ = Abendessen Zeigen Sie CONCERT (allgemeine Felder, Generic_Count als Sitze) WHERE type = Concert

Geben Sie dann KEINEN für EVENT auswählen

Aber hier kommt man in Schwierigkeiten, indem man nicht zuerst mit einem konzeptionellen Datenmodell beginnt.

Sie hätten eine ENTITY für EVENT und eine weitere für DINNER, die vollständig von EVENT und eine andere für CONCERT erbt, die vollständig von EVENT erbt. Dann könnten Sie eine Differenzierungsspalte im Vererbungsobjekt setzen, mit der Sie die Spalte "TYPE" einstellen können. Dann können Sie sogar entscheiden, wie viele Tabellen Sie mit einem Schalterwechsel erstellen möchten. 1 Tisch, 2 Tische oder 3 Tische ..

Zumindest können Sie das im powerDesigner machen.

Warum wird DDL als so schlecht angesehen?

Die Erstellung von EAV-Modellen und Fragen wie dieser ist um die Idee organisiert, dass DDL vermieden werden soll. Warum ALTER TABLE, wenn Sie eine neue Attributzeile einfügen können? Leute treffen schlechte Datenmodellentwurfsentscheidungen, die auf der falschen Dienstprogrammfunktion basieren. Diese Funktionen sind Dinge wie 'keine nullbaren Spalten', 'je weniger die Tabellen, desto besser', 'keine ddl, nur um ein neues Attribut hinzuzufügen. Fügen Sie stattdessen in die Attributtabelle 'ein.

Denken Sie an Datenmodellierung wie folgt: Bildhauer werden sagen, dass das Holz oder der Stein bereits die Figur innerhalb des Blocks hat, sie entfernen nur Teile davon, um es zu enthüllen.

Ihr Problembereich hat bereits ein Datenmodell, es ist nur Ihre Aufgabe, es zu entdecken ... es wird so viele Tabellen und Spalten haben, wie es benötigt. Zu versuchen, es zu zwingen, einer der oben genannten Nutzenfunktionen zu entsprechen, ist, wo Dinge schrecklich schief gehen.

Würdest du in deinem Fall gerne alle Veranstaltungen kennen, die du in den letzten zwei Wochen hinzugefügt hast? Denken Sie jetzt an die möglichen Modelle. Eine Tabelle pro Ereignistyp würde das Summieren über n Tabellen bedeuten, um diese Antwort zu finden, und mit jedem neuen Ereignistyp wird eine neue Tabelle hinzugefügt, und jede Abfrage "Alle Ereignisse" würde sich ändern. Sie könnten eine UNION ALL-Ansicht dieser Tabellen erstellen, aber Sie müssen daran denken, jede neue Tabelle zur Ansicht hinzuzufügen. Das Debuggen durch Ansichten wie diese ist ein Schmerz.

Wenn Sie davon ausgehen, dass Sie viele Messwerte zu ALLEN Ereignissen benötigen, ist eine Tabelle sinnvoller (zumindest für einen bestimmten Teil Ihrer Ereignisdaten - wie Ereignisname, Sponsor-ID, Veranstaltungsort-ID, Ereignisstartzeit, Ereignisendzeit) , Ort zur Verfügung für die Einrichtung Zeit, etc.) Diese Felder sind (lassen Sie uns festlegen) sind für jede Veranstaltung gemeinsam.

Was nun mit den anderen Spalten zu tun? Zwei Optionen, Nullable Felder oder vertikal die Tabelle partitionieren. Das spätere ist eine Optimierung des ersteren. Und wenn Sie irgendwelche Datenbankoptimierungsbücher oder -blogs lesen, ist die Hauptsache, die ich von ihnen nehme, dass vorzeitige Optimierung tötet. Ich sehe Leute, die viele Strategien für Probleme implementieren, bevor sie überhaupt wissen, ob sie dieses Problem haben werden. Ein Kollege hatte eine langsame Frage, mit der er mir helfen wollte. Es wurde mit Optimizer-Hinweisen geladen. Ich entfernte sie und der SQL schrie ... Ich weiß nicht, WARUM er es angedeutet hat, aber er hat es nicht effektiv gemacht und ich bin mir ziemlich sicher, dass er nie ein Problem gesehen hat, also war dies alles nur vorzeitige Optimierung.

Vertikale Partitionierung ist etwas, das Sie tun, wenn Sie große Datenmengen haben und einige häufig verwendete Daten und andere Daten verwenden, die nicht so nützlich sind. Sie können eine Tabelle mit viel weniger Blöcken packen, wenn Sie nur einige der Commons packen. Mehr Zeilen pro Block = schnellere Tablescans ...wirkt sich nicht wirklich auf die Geschwindigkeit aus, in der eine einzelne Zeile über einen Index gefunden wird. Wie Sie sehen können, hat vertikale Partitionierung ein spezifisches Problem, das es lösen kann (andere auch wie Reihenverkettung). Wenn Sie sicher sind, dass das ein Problem sein wird, dann fangen Sie auf alle Fälle damit an.

Es hängt davon ab, wie drastisch Ihre Formen sind. Ich sage, dass verschiedene Felder für jeden Eintrag haben ... wenn 1 Feld mit mehreren Elementen darin ist, werden Abfragen nur viel schwieriger. Wenn Ihre Formulare nicht zu unterschiedlich sind, dann wäre eine Tabelle mit jedem möglichen Feld in Ordnung, aber wenn Ihre Tabelle mehr als 20 Felder enthält, würde ich vorschlagen, diese Tabellen aufzuteilen. Ich würde auch eine Header-Tabelle mit einem "Formulartyp" -Feld empfehlen, um die Suche zu erleichtern.

Sie sollten Ihre Tabelle so weit wie möglich normalisieren, um die Anzahl der Nullen in der Datenbank zu reduzieren. Aufzeichnungen sollten aussagekräftig sein, wenn sie gespeichert sind. Eine Methode könnte darin bestehen, eine Tabelle von Kategorien zu haben, die 1- & gt; m mit einer Tabelle von Ereignissen in Beziehung setzt. Dann könnten Sie eine Tabelle mit erwarteten Feldern in Formularen haben (geben Sie jedem eine Int-ID). Dann würde eine Zwischentabelle die tatsächlich übertragenen Daten speichern.