Newsgroup: it.comp.software.database
Titolo: PK autogenerate, amici o nemici?

Riprendo il discorso di qualche messaggio piu' indietro sulle PK 
autogenerate (id incrementali o come dir si voglia). 
Dato che mi pare un'argomento abbastanza dibattuto, ho scritto le mie 
idee sull'argomento e le ho messe sul web, prossimamente magari aggiungiamo 
un puntatore nelle FAQ.
Gradirei ricevere delle opinioni (contrarie o meno alle mie) pero' esposte in 
maniera logica e coerente, cosi' le accodo alle mie e vediamo di presentare
il tutto in modo logico per dare una trattazione sufficientemente completa
del problema (se si puo' dire cosi').
Vedete un po' 
http://www.soft-land.org/documenti/pk.html
Davide

 del problema (se si puo' dire cosi').
Velocemente: secondo me la trattazione del problema non può prescindere 
da alcune considerazioni sulla natura della tabella su cui si sta 
definendo la PK e dell'utilizzo che si dovrà farne.
La maggior parte degli esempi che citi sono relativi a tabelle di tipo 
"anagrafico" (tabella clienti, tabella articoli etc.): è ovvio che in 
quei casi è facile inventarsi una PK "di sintesi" e non (integralmente) 
automatica, che ha indubbiamente dei vantaggi dal punto di vista 
mnemonico ecc;
Ma se si parla di tabelle dedicate, che so, all'OLTP, al content 
management, o altri casi dove c'e' molta movimentazione di dati inseriti 
in maniera massiva senza alcun possibile indizio sul loro possibile 
contenuto, le PK "identity" sono praticamente insostituibili.
D'altra parte, sono contrario all'idea di definire PK costruite con la 
concatenazione selvaggia di più campi allo scopo di trovare una ennupla 
unica: il prezzo che paghi in termini di efficienza nel mantenere la 
data integrity è troppo alto. In casi analoghi, se non ti piacciono le 
Identity, allora meglio definire un "codice" arbitrario, ma una PK che 
usa sette o otto campi su una tabella magari da 12 mi pare assurdo.
Di nuovo, solo i miei pochi spiccioli di Euro ;-)
Ciao!
-- 
Fabrizio "Hermooz" Ermini

 definendo la PK e dell'utilizzo che si dovrà farne.
Ma io infatti non sostengo che l'ID autogenerato e' negativo sempre e
comunque, od ovviamente devi fare la tua analisi prima di proporre
l'una o l'altra, quello che sostengo e' che spesso (e volentieri) tale
analisi non c'e' e si sceglie l'autogenerato per motivi sbagliati.
Tengo comunque da parte la cosa per successiva inclusione.
Davide

quoto quello che dice 
dav...@yahoo.com
, perché quotare è divertente!!

oilà, dico anche la mia, và!!
anch'io sono dell'idea che nella quasi totalità dei casi non serva un id 
autoincrementato e gran parte dei tuoi appunti è IMO validissima.
però ci sono davvero casi in cui è preferibile avere un id univoco da 
associare al record.
il primo esempio che mi viene in mente è che la mia bolletta del telefono 
(al di fuori della ladrata e tutto il resto), riporta sì i miei dati, ma 
anche il codice cliente che è un numerone, e quando telefono, mi chiedono 
subito se so il codice cliente per fornirglielo.
sarebbe impensabile:
1. una chiave spalmata sui dati anagrafici
 perché i dati anagrafici sono lì per essere modificati (cambio residenza 
ecc)
2. su una chiave come il codice fiscale, perché è possibile, seppur 
incredibile, che ci sia lo stesso codice fiscale per due persone differenti.
a questo punto verrebbe in mente di effettuare una specie di MD5 sui dati 
anagrafici al momento della registrazione, ma devi avere la certezza 
dell'univocità, quindi tanto vale affidarsi ad una chiave numerica che tra 
l'altro, essendo una sequenza canonica, è anche più veloce nella ricerca.
un altro punto che vedo a favore e decisamente indubbio (sempre rimanendo 
nelle telefoniche, che conosco un po' meglio) è che il processo di 
gestione, controllo fatturazioni ecc. è complessissimo e richiede migliaia 
di tabelle di cui molte da relazionare col cliente.
ridondare per migliaia di tabelle nome, cognome, città, data di nascita 
ecc. del cliente, è superfluo nonché uno spreco di spazio enorme, 
ritornando alla canonicità di una sequenza numerica ordinata (o anche 
pensando alla definizione di un base64 da 32 caratteri, che è comunque 
inferiore come lunghezza al solo campo 'nome' del cliente), quando 
tutto il calcolo della fatturazione avviene in modo indipendente dal dato 
anagrafico.
insomma, la chiave adatta è quasi sempre dipendente dal campo informazione, 
ma a volte (IMHO) non è così!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.nist.gov/dads/

 di tabelle di cui molte da relazionare col cliente.
Questo e' infatti uno dei motivi "pro" per avere una PK corta.
Davide

 hemmm... il tuo numero di telefono e' univoco giusto?
No, in alcuni casi vengono riassegnati (o comunque e' stato fatto
in passato, io per esempio ho perso il mio al paesello)
Ciao,
--
Gianluca Hotz
Backoffice MVP (SQL Server) MCP SQL Server and MCP Windows
Vice-President of the Italian User Group for SQL Server
Founding Member of the Italian User Group for .NET
http://www.ghotz.com
http://www.ugiss.org

 e che dubito sia autoincrementante.
però è autogenerato!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/gnu/manifesto.it.html

 Vedete un po' 
http://www.soft-land.org/documenti/pk.html
viste...e do la mia 2 cents...
quasi d'accrodo con quello che dici...
piccole considerazioni:
"Nel 98% dei casi che mi sono ritrovato davanti
in cui una tabella aveva un'ID autogenerato vi erano
un numero sufficiente di campi univoci da produrre
un'ottima chiave non-autogenerata per la tabella stessa"
FALSISSIMO!!!!
la percentuale è il 100%.... ;)
"Se l'unico campo valido in una tabella e' l'ID,
la possibilita' di ritrovarsi con 'n' record identici
(salvo l'ID) aumenta."
FALSO: dovresti conoscere il significato di AK..
"Riprendendo [...] per ricercare un cliente non
si puo' utilizzare l'ID perche' tale ID non ha senso
e l'utente non lo conosce, dovra' pertanto usare
o una ricerca alfabetica o altro sistema, [...]"
FALSO: ti rimando sempre ad AK
IMHO... è necessario distinguere il contesto
a) logico
b) fisico
in un contesto logico utilizzare le (chiamiamole) ID
è quantomeno indice di non aver capito un cazzo
riguardo il disegno di basi di dati... (ops ho detto
cazzo? volevo dire ca%%o)
in un contesto fisico la mia opinione forse diverge
da quello che sostieni...
PK come codice fiscale e/o numero telefonico sono
sicuramente esempi più che validi... ma quando in
realtà la chiave è composta da più campi (=>3)
secondo me è necessario utilizzare le chiavi "fisiche"
o meglio i vituperati ID autogene[rati|anti].
Le ragioni che mi vengono in mente dopo 4 pinte
e un cointreau sono:
1) maggiore efficienza e chiarezza nelle query
2) maggiore efficienza e chiarezza nelle SP e/o
business logic dell'applicazione
3) maggiore gestibilità dell'applicazione
or ora datemi un consiglio :)
 Flight Event
---------------------
pk    IATA code
pk    number
pk    postfix
pk    scheduled date
pk    inbound/outbound
pk    type
pk    class
pk    origin
che faccio... ce lo metto un id o la lascio così?
/G

 che faccio... ce lo metto un id o la lascio cosě?
Prima spiega il significato dei campi.
Davide


non sarebbe dovuto essere rilevante...
cmq... fatto
/G

 non sarebbe dovuto essere rilevante...
CERTO che e' rilevante! Come 'azzo fai a stabilire quale e' la migliore
chiave se non considerando il significato dei vari campi e come la tabella
si mette in relazione con il resto del sistema, come la tabella stessa
verra' usata etc. etc. ? Questa si chiama analisi del database.
Davide

 chiave se non considerando il significato dei vari campi e come la
tabella
la descisione della PK è una decisione logica...
e comunque nel nostro esempio esulava dal contesto...
non si stava discutendo su un modello per la gestione aeroportuale
la decisione di una AK e di un ID è una decisione che viene
presa nella modellazione fisica della base dati e non nella
fase di modellazione logica...stop...
un campo ID è un campo che deve essere introdotto nella
modellazione fisica, e il significato dei campi nella modellazione
fisica è *IR-RI-LE-VAN-TE*
certo che ci sono anche db[a|developer] in giro che non
sanno la differenza tra modello logico e fisico...
ma questo è un altro paio di maniche...
/G