Ist in diesem speziellen Szenario ein Primärschlüssel erforderlich?

Question

Ich habe einen Namen Tabelle mit (id, first_name, middle_name, last_name, Geschlecht) und eine E-Mail-Tabelle mit (id_fk, Email_add)

Infact ich ähnliche Tabellen der zweiten Art werden mit, wie ein Telefon Tisch (id_fk, phone_no), wobei id_fk der Fremdschlüssel ist, der sich auf die ID in der Namenstabelle bezieht.

Ist es erforderlich oder eher gibt es einen guten Grund, einen Primärschlüssel in der zweiten und dritten Tabelle zu haben? Oder andere ähnliche Tabellen? Oder würden Sie ein anderes Schema vorschlagen?

PS: Die Tische sind für einen Kontakt App

Answer 1

Sie sind fast immer besser dran mit einem Primärschlüssel. Auch wenn Sie denken, dass es jetzt nicht benötigt wird, wenn Ihre Datenbank wächst und komplizierter wird, werden Sie schnell auf Probleme ohne eine solche stoßen.

Persönlich würde ich auch empfehlen, eine datenunabhängige Spalte für Ihren Primärschlüssel etwas wie eine GUID/UUID/serielle. Wenn Sie ein Feld verwenden, das keine verwendbaren Daten enthält, werden Sie sich niemals in einer Situation befinden, in der Sie den Primärschlüssel aktualisieren müssen, was eine weitere unordentliche Operation sein kann, sobald Ihre Datenbank wächst.

Answer 2

In den Fällen, Speichern Sie, der Primärschlüssel ist die gesamte Tabelle (id_fk, PHONE_NO), da die Zeilen nicht andersweitig, repräsentieren eine ungeordnete Sammlung beschreiben und haben nur Wert und nicht irgendeine Art von Identität.

Answer 3

Es gibt einen Primärschlüssel für die Telefontabelle. Jedes Paar (id_fk, phone_no) definiert jeden Eintrag eindeutig, so dass in diesem Fall der Primärschlüssel ein zusammengesetzter ist.

http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx

Answer 4

Sie könnten (Fremdschlüssel, Telefonnummer) einen zusammengesetzten Primärschlüssel erstellen.

Persönlich bevorzuge ich die Verwendung von streng technischen Primärschlüssel, typischerweise eine Auto-ID-Spalte. Einer der Vorteile ist, dass es das Aktualisieren und Löschen von Datensätzen mithilfe der ID erleichtert, statt sich an den alten Wert in HTML-Formularen usw. zu erinnern.

Answer 5

Ich würde einen einfachen automatisch inkrementierenden "ID" Primärschlüssel zu jeder dieser Tabellen hinzufügen, es kostet sehr wenig und macht es einfacher, bestimmte Zeilen später zu referenzieren.

Es könnte auch eine gute Idee sein, ein anderes Benennungsschema für Ihre Fremdschlüssel zu betrachten, "id_fk" könnte etwas verwirrend sein, da es keinen Hinweis darauf gibt, auf welche "id" der Tabelle es sich bezieht, name_id "könnte eine bessere Wahl sein.

Answer 6

Sie sollten auf jeden Fall einen Primärschlüssel für alle Ihre Tabellen haben. Im Fall von (id_fk, phone_no) könnten Sie entweder einen zusammengesetzten Schlüssel verwenden, der aus beiden Spalten besteht, oder Sie könnten eine weitere Spalte als Primärschlüssel hinzufügen. Ich würde das Letztere empfehlen, da es letztendlich die Komplexität von allem reduzieren wird und viel angenehmer sein wird, wenn Sie ein ORM verwenden.

Answer 7

Warum benötigen Sie separate Tabellen für E-Mail-Adressen und Telefonnummern? Sie alle in derselben Tabelle zu speichern, ist viel effizienter. Ihr Schema könnte wie folgt aussehen:

(Pseudo SQL)

Create table ContactName (
     CONTACT_ID integer not null default auto_increment, 
     etc 
     ) 

CREATE TABLE TELECOM_CLASSES (
    CLASS_ID INTEGER NOT NULL DEFAULT AUTO_INCREMENT, 
    CLASS_NAME VARCHAR(200) NOT NULL 
       CHECK (CLASS_NAME IN ('email','tel','fax',etc)), 
    etc 
    ); 

CREATE TABLE CONTACT_TELECOMS (
    TELECOM_ID INTEGER NOT NULL DEFAULT AUTO_INCREMENT, 
    CONTACT_ID INTEGER NOT NULL REFERENCES CONTACTNAME (CONTACT_ID), 
    CLASS_ID INTEGER NOT NULL REFERENCES TELECOMS_CLASSES (CLASS_ID), 
    TELECOM VARCHAR(200) NOT NULL, 
    etc 

); 

Answer 8

Meine Design-Philosophie ist, dass jeder Tisch hat immer eine einzelne int Identität pk Spalt.

Dies scheint eine umstrittene Entscheidung zu sein, wie frühere Kommentare zu SO gezeigt haben, aber es ist auch sehr praktisch.