Ich habe eine kleine Verwirrung über das Entwerfen des Schemas, aber bevor ich beginne, zeige ich Ihnen zuerst das Schema,
%Vor% und die Verwirrung ist hier, die Zuordnung Tabelle für Tabellen: Person und JobDescription . Derzeit habe ich dieses Design,
aber ich habe diese andere Idee, welche Struktur der Mapping-Tabelle so sein wird
%Vor%Wenn ich die Abfrage für die obigen Tabellen erstellt und getestet habe, geben beide die gleichen Ergebnisse zurück, und die Leistung ist auch dieselbe wie beim Testen auf einer kleinen Datenbank ( mit 50.000 Datensätzen ). Ich frage mich, ob sich die beiden Abfragen in einer großen Datenbank verhalten.
FRAGEN
Person_JobDescription ) bevorzugen Sie in einer großen Datenbank? Wie beschrieben, darf ich keine UNIQUE Einschränkung für FirstName und LastName erstellen. Aber ich habe einen Index für die zwei Spalten geliefert.
Person ? Ein Index für jede Spalte oder ein zusammengesetzter Index für FirstName und LastName ? INDEX (Col1) und INDEX (Col2) über INDEX (Col1, Col2) ? Danke, dass Sie sich die Zeit genommen haben, diese Frage zu lesen.
Beste Grüße,
Derek Floss
Ich würde den zweiten Ansatz bevorzugen. Wenn Sie Ersatz-ID-Nummern verwenden, wenn sie für die Identifizierung nicht logisch erforderlich sind, führen Sie mehrere obligatorische Joins ein. Dies erfordert, dass Sie "ID-Nummern über die gesamte Datenbank verfolgen", was der SQL-Entsprechung zu "Verfolgen von Zeigern in der gesamten Datenbank" entspricht. Die Verfolgung von Zeigern war charakteristisch für IMS, eine der Datenbankarchitekturen, die das relationale Modell ersetzen sollte. (IMS verwendet eine hierarchische Architektur.) Es hat keinen Sinn, es heute neu zu erfinden. (Obwohl ein viel von Leuten genau das tun.)
Wenn Sie zum Beispiel fünf Ebenen von Ersatz-ID-Nummern haben und den Namen einer Person haben möchten, müssen Sie vier Joins machen, um sie zu erhalten. Mit dem zweiten Ansatz brauchen Sie nur einen Join. Wenn Sie keine mehrspaltigen Joins schreiben möchten, verwenden Sie CREATE VIEW und machen Sie es nur einmal.
Leistung ist einfach zu testen . Generieren Sie einfach einige Millionen zufällige Zeilen mit Ihrer bevorzugten Skriptsprache und laden Sie sie auf einen Testserver. Sie werden nicht nur feststellen, wo sich Ihre Leistungsprobleme verbergen, Sie werden alle Fehler in Ihrem CREATE TABLE-Code finden. (Ihr Code funktioniert nicht wie er ist.) Weitere Informationen zu EXPLAIN erhalten Sie, wenn Sie nicht möchten Ich weiß es noch nicht.
Wie bei der Indizierung können Sie das in den zufällig generierten Zeilen testen, die Sie generieren und laden. Ein mehrspaltiger Index für (vorname, nachname) funktioniert am besten, wenn Benutzer immer einen Vornamen angeben. Aber viele Benutzer werden das nicht tun, sondern lieber nach Nachnamen suchen. Ein mehrspaltiger Index für (vorname, nachname) ist nicht effektiv für Benutzer, die nach Nachnamen suchen möchten. Sie können das testen.
Aus diesem Grund ist die Indizierung von Vornamen und Nachnamen in der Regel normalerweise effektiver, wenn es zwei separate Indizes gibt, einen für den Vornamen und einen für den Nachnamen.
Was bedeutet das Verfolgen von ID-Nummern ?
Das unausgesprochene Entwurfsmuster, das dieser Frage zugrunde liegt, lautet "Jede Zeile muss eine ID-Nummer haben und alle Fremdschlüssel müssen auf die ID-Nummer verweisen." In einer SQL-Datenbank ist es eigentlich ein Anti-Pattern. Als Faustregel gilt, dass jedes Muster, das es erlaubt, Tabellen zu entwerfen, ohne über Schlüssel nachzudenken, solange für schuldig befunden wird, bis es sich als unschuldig erwiesen hat - es sollte als ein Anti-Muster betrachtet werden, bis es bewiesen ist.
%Vor%Wenn Sie einen Bericht über Tabelle "D" benötigen und der Bericht
benötigtSie brauchen 3 Joins, um dorthin zu gelangen. (Probieren Sie es aus.) Sie jagen ID-Nummern. (Wie die Verfolgung von Zeigern in IMS.) Die folgende Struktur ist anders.
%Vor%Bei dieser Struktur benötigt derselbe Bericht einen einzelnen Join.
%Vor%Der erste Ansatz wäre meine Präferenz
Wenn Sie eine Tabelle benötigen, die von PersonJobDescription abhängig ist, sagen Sie AgentContact, können Sie leicht auf das Ersatzzeichen Rec_ID verlinken, ohne das Sie durch Hoops springen müssen
Der andere Grund wäre, wenn es erforderlich wäre, für jedes Jahr eine Person / JobDescription zu führen? Bevor Sie wissen, wo Sie sind, haben Sie einen Vier-Vakue-Compound-Schlüssel, der immer noch nicht die Aufgabe erfüllt. Die Regel Compound Primary Keys sollte ein letzter Ausweg sein, um Ihre Designs flexibler und widerstandsfähiger zu machen.