Reichen 1 zu 1 Beziehungen auf db-Tabellen?

Question

Ich habe eine Tabelle, die eine Reihe von Feldern hat. Die Felder können in logische Gruppen unterteilt werden - wie die Projektmanagerinfo eines Jobs. Die Gruppierungen selbst sind nicht wirklich Entitätskandidaten, da sie keine eigenen PKs haben und auch nicht haben sollten.

Für jetzt, um sie zu gruppieren, haben die Felder Präfixe (PmFirstName zum Beispiel), aber ich überlege, sie in mehrere Tabellen mit 1: 1 Beziehungen auf der Haupttabelle zu brechen.

Gibt es etwas, auf das ich achten sollte, wenn ich das tue? Ist das nur eine schlechte Wahl?

Ich kann sehen, dass meine Abfragen vielleicht komplizierter werden mit all den zusätzlichen Joins, aber das kann mit Ansichten gemildert werden, oder? Wenn es sich um eine Tabelle mit weniger als 100.000 Datensätzen handelt, wird sich dies spürbar auf die Leistung auswirken?

Edit: Ich werde die Nicht-Entität Kandidaten Gedanken ein wenig weiter rechtfertigen. Diese Information wird von unserer Benutzerbasis eingegeben. Sie wissen nicht/kümmern sich nicht umeinander. Es ist also möglich, dass derselbe Benutzer den gleichen "ProjectManager-Namen" oder was auch immer einreicht, was an dieser Stelle keine Beschränkung verletzen würde. Es ist für uns später festzustellen, ob wir die Einträge von einzelnen Benutzern korrelieren wollen. Wenn ich diesen Dingen ihren eigenen Schlüssel geben würde, würden sie mit der gleichen Geschwindigkeit wachsen, mit der der Haupttisch wächst - da sie im wesentlichen Teil derselben Entität sind. Bei keinem Punkt wählt ein Benutzer eine Liste von verfügbaren "Projektmanagern" aus.

Also, angesichts der oben genannten, glaube ich nicht, dass sie Entitäten sind. Aber vielleicht nicht - wenn Sie weitere Gedanken haben, schreiben Sie bitte.

Answer 1

Ich verwende normalerweise keine 1: 1-Beziehungen, es sei denn, es gibt einen bestimmten Leistungsgrund dafür. Speichern Sie beispielsweise ein selten verwendetes großes Text- oder BLOB-Typenfeld in einer separaten Tabelle.

Ich würde vermuten, dass hier noch etwas anderes vor sich geht. In dem Beispiel, das Sie geben - PmFirstName - scheint es, als ob es vielleicht eine einzige PM_ID geben sollte, die sich auf eine "ProjectManagers" oder "Employees" -Tabelle bezieht. Sind Sie sicher, dass keine dieser Gruppierungen wirklich Entitätskandidaten sind?

Answer 2

Für mich riechen sie, es sei denn für einige Zeilen oder Abfragen werden Sie nicht an den zusätzlichen Spalten interessiert sein. z.B. Wenn Sie für einen großen Teil Ihrer Abfragen nicht die PmFirstName-Spalten auswählen, oder wenn diese Spalten für eine große Teilmenge von Zeilen NULL sind.

Ich mag den Geruchstag.

Answer 3

Warum glauben Sie, dass die Gruppe von Feldern keine Entitätskandidaten sind? Wenn das nicht der Fall ist, warum versuchen Sie, sie mit einem Präfix zu identifizieren?

Entweder die Präfixe löschen oder sie in ihre eigene Tabelle extrahieren.

Answer 4

Ich verwende 1 zu 1 Beziehungen für vererbungsähnliche Konstrukte.

Zum Beispiel haben alle Anleihen einige grundlegende Informationen wie CUSIP, Coupon, DatedDate und MaturityDate. Das alles geht in die Haupttabelle.

Jetzt hat jede Art von Anleihe (Treasury, Corporate, Muni, Agency usw.) auch ihre eigenen Spalten, die für sie einzigartig sind.

In der Vergangenheit hätten wir nur eine unglaublich breite Tabelle mit all diesen Informationen. Jetzt teilen wir die typspezifischen Informationen in separate Tabellen auf, was uns eine viel bessere Leistung bringt.

Zum jetzigen Zeitpunkt haben die Felder Präfixe (zum Beispiel PmFirstName), aber ich überlege, sie in mehrere Tabellen mit 1: 1 Relationen in der Haupttabelle zu zerlegen.

Erstellen Sie eine Personentabelle, jede Datenbank benötigt dies. Dann haben Sie in Ihrer Projekttabelle eine Spalte namens PMKey, die auf die Personentabelle zeigt.

Answer 5

Es ist sinnvoll, sie in separate Tabellen aufzuteilen, wenn sie separate logische Einheiten sind, die an anderer Stelle verwendet werden können.

So ein "Projektmanager" könnte 1: 1 mit allen Projekten zur Zeit sein, aber es macht Sinn, dass Sie später in der Lage sein können, einen Projektmanager mehr als ein Projekt zu haben. Also die extra Tabelle ist gut.

Wenn Sie eine PrimaryFirstName, PrimaryLastName, PrimaryPhone, SecondaryFirstName, SecondaryLastName, SEcondaryPhone

Sie könnten nur eine "Person" Tisch mit Vorname, Nachname, Telefon

Dann Ihre ursprüngliche Tabelle benötigt nur „PrimaryId "und" SecondaryId "Spalten, um die 6 Spalten zu ersetzen, die Sie zuvor hatten.

Mithilfe von SQL können Sie Dateigruppen und Tabellen auch über physische Standorte hinweg aufteilen. Sie könnten also eine POST-Tabelle und eine COMMENT-Tabelle mit einer 1: 1-Beziehung haben, aber die COMMENT-Tabelle befindet sich in einer anderen Dateigruppe und auf einem anderen physischen Laufwerk mit mehr Speicher.

1: 1 riecht nicht immer. Es sei denn, es hat keinen Zweck.