Ordnungsgemäße Verwendung von Nachschlagetabellen

In Ihrer Employees-Tabelle würde ich nur nach "Position" suchen, da es sich um einen begrenzten Datensatz handelt, der erweitert werden kann.

• Das Geschlecht ist selbstbeschreibend (z. B. M oder F), auf 2 Werte begrenzt und kann mit einer CHECK-Einschränkung erzwungen werden. Sie werden keine neuen Geschlechter hinzufügen (politische Korrektheit ignorieren).
• Der Vorname "John" ist nicht Teil eines begrenzten, eingeschränkten Datensatzes: Der potenzielle Datensatz ist so groß, dass er praktisch unbegrenzt ist, sodass er nicht nachgeschlagen werden sollte

Wenn Sie eine neue Position hinzufügen möchten, fügen Sie der Nachschlagetabelle einfach eine Zeile hinzu. Dadurch werden auch Datenänderungsanomalien entfernt, was ein Punkt der Normalisierung ist

Sobald Sie eine Million Mitarbeiter haben, ist es effizienter, tinyint PositionID als varchar zu speichern.

Fügen wir eine neue Spalte "Gehaltswährung" hinzu. Ich würde hier eine Nachschlagetabelle mit einem Schlüssel von CHF, GBP, EUR, USD usw. verwenden: Ich würde keinen Ersatzschlüssel verwenden. Dies könnte durch eine CHECK-Einschränkung wie Geschlecht eingeschränkt werden, es handelt sich jedoch um einen begrenzten, aber erweiterbaren Datensatz wie Position. Ich gebe dieses Beispiel, weil ich den natürlichen Schlüssel verwenden würde, selbst wenn er in einer Million Zeilen von Mitarbeiterdaten angezeigt wird, obwohl er eher char (3) als tinyint ist

Zusammenfassend verwenden Sie also Nachschlagetabellen

1. wo Sie eine endliche, aber erweiterbare Menge von Daten in einer Spalte haben
2. wo ist nicht selbstbeschreibend
3. zu vermeiden Datenänderungsanomalien

Die Antwort lautet "es kommt darauf an". Nicht sehr befriedigend, aber es gibt viele Einflüsse, die das Design drücken und ziehen. Wenn App-Programmierer die Datenbank entwerfen, funktioniert eine von Ihnen beschriebene Struktur für sie, da der ORM die Komplexität verbirgt. Sie werden sich beim Schreiben von Berichten die Haare ausreißen und müssen an zehn Tischen teilnehmen, um eine Adresse zu erhalten.

Design für die Verwendung, den beabsichtigten Gebrauch und die wahrscheinliche zukünftige Verwendung. Hier kommt Ihr Wissen über den Geschäftsprozess ins Spiel. Wenn Sie eine Datenbank für ein Veterinärunternehmen entwerfen, gibt es vernünftige Annahmen über Größe, Verwendung und Anweisungen in Bezug auf die Funktionalität, die sich erheblich von denen eines High-Tech-Start-ups unterscheiden.

Ein Lieblingszitat wiederverwenden

"Ein weiser Mann hat mir einmal gesagt" normalisieren, bis es weh tut, denormalisieren, bis es funktioniert ".

Irgendwo drin ist der Sweet Spot. Ich habe die Erfahrung gemacht, dass es nicht so schwerwiegend ist, eine Schlüssel-ID in mehr als einer Tabelle zu haben, wie manche denken, wenn Sie niemals Primärschlüssel ändern.

Nehmen Sie dieses abgekürzte Beispiel für stark normalisierte Tabellen aus einem realen System

CREATE TABLE PROPERTY
(ID                          NUMBER(9)           NOT NULL);

CREATE TABLE PROPERTY_TYPE
(ID                          NUMBER(9)           NOT NULL);

CREATE TABLE PROPERTY_LOCALE 
PROPERTY_ID                  NUMBER(9)           NOT NULL,
(LOCALE_ID                   NUMBER(9)           NOT NULL,  --language 
VALUE                        VARCHAR2(200)       NOT NULL);

CREATE TABLE PROPERTY_DEPENDENCY
(PROPERTY_ID                 NUMBER(9)           NOT NULL,
 PARENT_PROPERTY_ID          NUMBER(9)                   ,
 PROPERTY_TYPE_ID            NUMBER(9)           NOT NULL);

Diese Tabellen erstellen eine verknüpfte Liste einzelner Eigenschaften und übergeordneter untergeordneter Eigenschaften und werden hier verwendet

  CREATE TABLE CASE_PROPERTY
  (ID                        NUMBER(9)           NOT NULL,
  PARENT_ID                  NUMBER(9),
  CASE_ID                    NUMBER(9)           NOT NULL,
  PROPERTY_ID                NUMBER(9),
  PROPERTY_TYPE_ID           NUMBER(9)           NOT NULL);

Das sieht gut aus: Holen Sie sich alle Fälle mit einer property_id in einer Auswahl

Lassen Sie uns eine Liste zur Auswahl bekommen

 Select pl.value, pd.property_id
 from property_locale pl, property_dependency pd
 where pl.property_id = pd.property_id
 and pd.property_type_id = 2;  --example number

Versuchen Sie nun, alle Eigenschaften eines Falls auszuwählen, wenn er Eigenschaftstypen von 3 und 4 und 5 hat oder nicht ...

SELECT   cp2.case_id,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 2
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE1,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 34
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE2,
         (SELECT   pl.VALUE
            FROM   case_property cp, property_locale pl
           WHERE       cp.property_id = pl.property_id
                   AND CP.PROPERTY_TYPE_ID = 4
                   AND pl.locale_id = 2
                   AND cp.case_id = cp2.case_id)
            AS VALUE3
  FROM   case_property cp2
 WHERE   cp2.case_id = 10293  

Das tut einfach weh ... auch wenn Sie eleganter damit umgehen. Fügen Sie jedoch ein wenig De-Normalisierung hinzu, indem Sie Eigenschaften aufteilen, für die ein Fall nur eine property_id hat, und dies könnte viel besser sein.

Um herauszufinden, wann Sie zu viele Tabellen haben oder nicht genug, versuchen Sie, die Datenbank mit Fragen abzufragen, die die Anwendung, ein Bericht und eine Analyse von Jahr zu Jahr verwenden.