Datenbank-Design: Definieren einer Beziehung zwischen Entitäten in der Datenbank

Question

Ich möchte eine Datenbank für meine Anwendung entwerfen, und ich habe eine Frage über die Möglichkeit, eine Beziehung zwischen den Entitäten zu definieren.

Ich habe 2 verwandte Entitäten, deren ID Verbindung ist. Zum Beispiel:

• eine Adresse Einheit, die durch die Eigenschaften [Hausnummer, Hausnummer, Stadt, Land], und eine Telefonnummer (xx-yyyyyy)
• ein Unternehmen identifiziert werden, die durch die Eigenschaften identifiziert [Regionsnummer, die Nummer].

Die Beziehung ist „Für jede Adresse gibt es mehrere Telefonnummern Ich habe zwei Möglichkeiten, um die Tabellen zu definieren.

1. Tabellen, die von allen ID-Felder verbunden
   • Adresse → [Hausnummer, Hausnummer, Stadt, Land, ..., Regionalnummer, die Nummer]
   • PhoneNumber → [Regionsnummer, die Nummer, ...]
2. Tabellen mit einem ID-Feld (GUID), das über dieses Feld verbunden ist.
   • Adresse → [ID, Hausnummer, Hausnummer, Stadt, Land, ...,]
   • Phone → [ID, Region Nummer, die Nummer, ..., AddressID]

In der ersten Lösung sind der Primärschlüssel alle Felder, die die Entität identifizieren, und in der zweiten Lösung ist der Primärschlüssel nur das ID-Feld.

Meine Frage ist - was ist der bessere Weg? (Durch Leistung, Wartung, Design, etc ...)

Answer 1

Der Primärschlüssel wird nie "in einer Tabelle alle Felder" sein. So sollen relationale Datenbanken nicht funktionieren, also vergessen Sie diesen Ansatz.

Der Schlüssel ist ein Schlüssel, und Daten sind Daten. Mischen Sie die beiden nie. Wenn Sie sie mischen, kommt es zu einer Situation, in der Sie den Schlüssel und alle Datensätze in der Datenbank, die ihn verwenden, ändern müssen, sobald sich die Daten ändern. Was schlecht ist.

Der einzige richtige Weg, dies (common) 1 entwerfen: n-Beziehung ist:

 
Address    PhoneNumber 
-------    ----------- 
*ID   <---+  *ID 
StreetNumber +--- AddressID 
HouseNumber   RegionNumber 
City     TheNumber 
Country    ... 
... 

Die * Primärschlüssel bezeichnen, die typischerweise eine Auto-Inkrementieren-Nummer mit einem eindeutigen Index auf sich.

Der Pfeil kennzeichnet eine Fremdschlüsselbeziehung.

Answer 2

Ob Sie haben G UID die zweite Option ist einfacher zu programmieren und zu programmieren. Wenn Sie Daten auswählen, indem Sie zwei Tabellen verknüpfen, benötigen Sie nur die indexierten Bezeichnerspalten. Der andere Weg, den Sie brauchen, zusammengesetzte Indizes für nur diese Verbindung.

Das Vorhandensein von eindeutigen Primärschlüsseln in Tabellen in einem Unternehmenssystem ist nach meiner Erfahrung eine wertvolle Übung. (aus der DBA- und Entwicklerperspektive)

Das Entwerfen der Datenbank für die Leistung ist ein kompliziertes Problem, das viele Kriterien einbezieht. Gehen Sie dann lieber nach der Theorie, wenn Sie Oracle zur Hand haben, spielen Sie mit Ihren beiden Ansätzen in der Praxis und benutzen Sie EXPLAIN-Plan-Tools. Ich meine, erstellen Sie Tabellen mit Ihren erwähnten Ansätzen, spielen Sie mit Indizes und verwenden Sie EXPLAIN-Plan. Wenn ich mich nicht irre, gibt Ihnen Oracle sogar eine Vorstellung von der Abfrageleistung durch Projektion (d. H. Indem Sie die Anzahl der Zeilen in Tabellen schätzen). Ich bin mir nicht sicher, ob Express Edition Version diese Unterstützung hat