Quando ho imparato i database relazionali, il prof ha detto che uno "quasi sempre" vuole un int artificiale come chiave primaria in una tabella, ma non ha specificato quali sono le eccezioni. A un certo punto ho smesso di usarli per le tabelle di giunzione e non ho mai avuto problemi.
Ora sto creando un database con molte tabelle di ricerca e mi chiedo se questo è un caso in cui lasciare le chiavi artificiali non renderebbe un design più pulito e una programmazione semplice.
Un esempio di giocattolo: supponiamo che questo sia un mockup dell'interfaccia utente che voglio raggiungere.
L'opzionediprogettazioneconIDartificialisarebbe(Tipoèunachiaveesterna):
LiteraryWorkTitleTypeWinnieThePooh1TheNightingaleandtheRose2Snowwhite2LiteraryWorkTypeIDTypeName1Novel2FairyTaleEl'opzionesenzadiessiusailnomeditipostessocomechiave(dinuovo,iltipodicolonnaèdichiaratocorrettamentecomechiaveesterna):
LiteraryWorkTitleTypeWinnieThePoohNovelTheNightingaleandtheRoseFairyTaleSnowwhiteFairyTaleLiteraryWorkTypeTypeNameNovelFairyTaleTendoadusarelasecondaopzione,perchéavreibisognodiunjoininmenoquandomostriidatisulloschermo.(Nonvoglioeliminarecompletamentelatabelladiricercaperchévoglioessereingradodilimitareivalorichegliutentipossonoimmettere,adesempioassegnandolorounelencoadiscesaassociatoallatabelladiricerca).L'unicosvantaggiochepossopensareèche,quandounostakeholderdice"ma voglio che la mia UI dica" storia ", non" fiaba "", dovrei aggiornare tutte le righe di dati nella tabella LiteraryWork . Posso vivere con questo, perché non mi aspetto che accada spesso nel mio caso.
Il primo progetto presenta altri vantaggi che mi mancano? Quale delle due opzioni è considerata la migliore pratica e perché?
Modifica2 A quanto ho capito, le risposte esistenti temono che sto cercando di rompere la normalizzazione, come in
LiteraryWork
Title Type LiteraryWorkTypeIsFiction
Winnie The Pooh Novel Yes
The Nightingale and the Rose Fairy Tale Yes
Snowwhite Fairy Tale Yes
Per essere chiari: quanto sopra è non ciò che sto cercando di fare. Invece, se ci fossero davvero più informazioni relative a LiteraryWorkType e stavo usando gli ID stringa, lo registrerei in questo modo:
LiteraryWork
Title Type
Winnie The Pooh Novel
The Nightingale and the Rose Fairy Tale
Snowwhite Fairy Tale
LiteraryWorkType
TypeName IsFiction
Novel Yes
Fairy Tale Yes
Conference paper No
L'unica differenza con la struttura del database "tipico" sarebbe che l'ID è un nvarchar, non un intero. Che ha certamente i suoi svantaggi nella conservazione necessaria, come sottolineato, ma non vedo quale regola di normalizzazione si suppone faccia male.
Ma a parte questo esempio, non sto cercando di usare gli ID stringa quando effettivamente ci sono più informazioni da registrare su un oggetto LiteraryWorkType (in modo che LiteraryWorkType debba essere considerato un'entità a sé stante). Sto parlando di casi semplici come l'esempio del giocattolo che ho dato all'inizio: l'intera seconda tabella esiste solo perché SQL non ha il tipo "enum" e ogni record di dati in esso consiste di nient'altro che una singola parola, unica tra i record.