Chiave Primaria composta vs aggiuntive “ID” colonna?

Se abbiamo avuto un tavolo come questo:

Libri (finta “ISBN” non esiste)

  • Autore
  • Titolo
  • Edizione
  • Anno di pubblicazione
  • Prezzo

Si potrebbe sostenere che {Autore,Titolo,Edizione} potrebbe essere un candidato/chiave primaria.

Ciò che determina se la candidato/chiave primaria deve essere {Autore,Titolo,Edizione} o se la colonna ID dovrebbe essere utilizzato, con {Autore,Titolo,Edizione} un indice univoco/vincolo di chiave?

Così è

  • Autore (PK)
  • Titolo (PK)
  • Edizione (PK)
  • Anno di pubblicazione
  • Prezzo

meglio, oppure:

  • ID (PK)
  • Autore
  • Titolo
  • Edizione
  • Anno di pubblicazione
  • Prezzo

dove {Autore,Titolo,Edizione} è un ulteriore indice univoco/vincolo?

InformationsquelleAutor user997112 | 2013-01-29

 

4 Replies
  1. 45

    Dire che {Author,Title,Edition} identifica in modo univoco un libro, quindi le seguenti regole:

    1. Si tratta di un (super)chiave — identifica univocamente una tupla (riga).

    2. È irriducibile — rimozione di una qualsiasi delle colonne non è un tasto di più.

    3. È una chiave candidata — un irriducibile chiave è una chiave candidata.

    Consideriamo ora l’ID (intero)

    Riesco a ragione che il Book chiave per la tabella mostrerà in pochi altri tavoli come chiave esterna e anche in alcuni indici. Così, ci vorrà un po ‘ di spazio, diciamo tre colonne x 40 caratteri (o quello che è…) — in ciascuna di queste tabelle plus in corrispondenza degli indici.

    Per rendere questi “altri” indici e tabelle più piccole, è possibile aggiungere un unico-intero-colonna a Book tabella per essere utilizzato come una chiave che sarà di riferimento come chiave esterna. Dire qualcosa come:

    alter table `Book` add `BookID` integer not null identity;

    Con BookID essere (deve essere univoco troppo, il Book ora la tabella ha due chiavi candidate.

    Ora posso selezionare il BookID come chiave primaria.

    alter table Book add constraint pk_Book primary key (BookID);

    Tuttavia, il {Author,Title,Edition} deve soggiorno chiave (unico) per evitare qualcosa di simile a questo:

    BookID  Author      Title           Edition
    ----------------------------------------------- 
      1      C.J.Date  Database Design     1
      2      C.J.Date  Database Design     1

    Per riassumere, aggiungendo il BookID — e scegliendo come primario — non si è fermata {Author,Title,Edition} essere un candidato chiave. Ancora deve avere il suo unico vincolo e, di solito, il corrispondente indice.

    Anche notare che dal punto di progetto, questa decisione è stato fatto sul “livello fisico”.
    In generale, il livello logico di design, questo ID non esiste-che ha introdotto durante l’esame della colonna dimensioni e indici. Così lo schema fisico è derivato dalla logica. A seconda del DB dimensioni, RDBMS e hardware usato, niente di che dimensioni ragionamento può avere effetto misurabile — in modo che l’utilizzo {Author,Title,Edition} come PK, che potrebbe essere perfettamente buona progettazione — fino a prova contraria in modo diverso.

  2. 16

    In generale, non si desidera che la chiave primaria per cambiare il valore. Questo è il motivo per cui non vedente o surrogati, le chiavi primarie sono utilizzati.

    Supponiamo che avete creato il vostro tavolo Libro con l’Autore come parte della chiave primaria.

    Supponiamo che hai scoperto dopo un anno che hai scritto male “di Ray Bradbury”. O, ancora peggio, hai scritto male “Rachael Bloom”. Provate a immaginare quante righe del database è necessario modificare per correggere l’errore di battitura. Provate a immaginare quante indice riferimenti devono essere modificati.

    Tuttavia, se si dispone di un Autore tabella con una chiave surrogata, è solo per correggere una riga. No gli indici devono essere modificati.

    Infine, la tabella di database i nomi sono di solito singolare (Libro), piuttosto che al plurale (Libri).

    • Non sono d’accordo sul singolare vs. plurale (una tabella che contiene un insieme di qualcosa (ad esempio “libri”), anche se il set è solo una riga). Ma questo è completamente un altro argomento soggettivo e non appartengono qui IMHO.
    • Quando si dice surrogato intendi per ID/ISBN è quello da usare?
    • Voglio dire, una chiave primaria che non ha nulla a che fare con i libri a tutti. In generale, un numero intero che inizia da zero e incrementato di uno per ogni riga aggiunta. Io li chiamo cieco chiavi.
    • Singolare è la convenzione accettata in ER modellazione (ad esempio per la ricerca di “singolare” in ERwin Metodi di Guida). Inoltre, i nomi delle classi in OOP singolare, anche se potenzialmente possono essere istanziati molte volte. Ma io sono d’accordo questo è un po ‘ soggettivo e l’utilizzo di una diversa convenzione non è certamente un peccato capitale…
    • Sono d’accordo con Gilbert. Ho quasi sempre aggiungere qualche tipo di identificatore di riga (di solito un int colonna di identità) anche quando sembra che non ci sia qualcos’altro che potrebbe essere la chiave. Guarda questo – che è più facile aggiornare gli utenti where username = ‘jr33s22dt6uwwdrrws33ww’ o aggiornare gli utenti where userid = 4
    • Un altro pensiero – se avete qualcosa di errato (Rachael Boolm) e andare a rinominare se è la parte della chiave primaria – cosa succede se c’correttamente? Fissare sin da ora. Per cui, se non è parte della chiave, si può aggiornare e quindi avere qualcosa che controlla che più tardi piuttosto che vivere. E parlando per esperienza, c’è un alta probabilità che si finisce con lo stesso libro due volte.
    • Mi piacerebbe trovare il modo più facile per verificare le affermazioni sono corrette, sia quelli manuali, o quando il debug di codice, quando si riferiscono a campi che non hanno significato semantico, ad esempio, il titolo e l’autore. Ora nel libro esempio, infatti, l’autore+titolo combinazione è probabilmente inadatto per quanto riguarda i riferimenti da altri tavoli etc. e ISBN non necessariamente hanno il vantaggio che ho citato (almeno in modo ridotto). Ma in generale, se non vi è alcuna buona ragione per inventare un identificatore non parlare di me, preferisco utilizzare quello che fa.

  3. 7

    Un altro buon motivo per l’utilizzo di surrogati di chiave primaria scenario è se il vincolo di unicità dovrebbe cambiare in futuro (ad esempio, ISBN deve essere aggiunto per rendere un libro unico). Rielaborare i dati sarà molto più facile.

  4. 4

    Ci sono molti articoli correlati a questo.
    I problemi con il composito chiave nel tuo caso:

    1. difficile collegare i libri con altri enti
    2. Difficile da modificare in una griglia come la maggior parte delle reti sono non supporta le chiavi composte (ad esempio, il kendo griglia, jqgrid)
    3. Si potrebbe digitato correttamente Autore, Titolo, Edizione

    Sarebbe anche un bene per normalizzare i vostri dati e memorizzare solo un ID per l’autore come (dasblinkenlight) ha suggerito. Peggiore dei casi, sarà lui/lei a cambiare la sua/il suo nome (ad esempio, si è sposata, e lei ama il suo nuovo nome).

Lascia un commento