Newsgroup: it.comp.www.php
Titolo: OT - scelta chiave

Salve
avendo una tabella con elementi quali
ID
A
B
C
D
dove gli elementi essendo univoci potrebbero essere essi stessi chiave, 
converrebbe comunque utilizzare degli indici numerici?
es.
ID Campo
1  A
2  B
3  C
4  D
5  E
grazie


se gli elementi sono di per sè chiave a che pro inserire una chiave 
numerica?
poi la chiave può essere univoca oppure no, ma questo è altro discorso.
poi stai confondendo chiave con indici, ricorda che sono cose differenti.
un indice serve per effettuare delle ricerche in maniera più veloce 
(quindi quando si effettuo una select su un indice il dbms consulta una 
parte (indice appunto) per individuare il record, mentre se si effettua 
una ricerca con campi senza indice il dbms è costretto ad effettuare un 
table space scan ,cioè leggere riga per riga per individuare il campo 
ricercato), ma non c'entrano nulla con la chiave primaria o secondaria.
gli indici appesantiscono le scritture come insert/delete/update (questo 
perchè il dbms deve inserire oltre al record in tabella il/i relativo/i 
indice), mentre velocizza in lettura, inserire troppi indici è come non 
inserirli affatto.
valuta bene quando crei una tabella come e dove inserire gli indici.
comunque sei OT
Ciao

2012 pensaci tu wrote:

E' l'eterno dibattito natural keys vs. surrogate keys. Ognuna di queste
soluzioni ha dei pro e contro. Dal punto di vista della teoria dei
database relazionali sono entrambe valide. Prova a gugolare un po' negli
infiniti thread presenti in rete sull'argomento per vedere se qualcuno
riesce a convincerti della bontà dell'una o dell'altra :)
	Y.


IMHO non vedo l'utilità di usare un ulteriore campo soprattutto
nell'esempio in questione dove la colonna sarebbe comunque piccola.
Chiaramente se Campo fosse un blob contenente un immagine gigantissima o
siminili si ricadrebbe nel problema esposto da bramante.
Insomma per l'esempio che hai postato io sono per non inserire un
inutile campo, anche se so che in genere si inserisce sempre e lo si
mette chiave primaria intera autoincrementale per non avere problemi di
cardinalità sulla primaria. ma questo vale solo per i DBMS che
supportano sta features.
Jeff

 nell'esempio in questione dove la colonna sarebbe comunque piccola.
Coerenza e pulizia.
Io amo vedere tabelle chiamate "tblQualcheCosa" con chiave
"idQualcheCosa" rigorosamente intero lungo.
Eventuali altri vincoli d'univocità li esprimo con vincoli opportuni e
indicizzo poi come opportuno.
La ragione è che se "normalizzi" molto i dati, ti ritrovi con tantissime
tabelle molto strette. Avere le chiavi rigirosamente formate da UN campo
sempre intero lungo facilita e di molto la lettura delle query quando
hai chiavi esterne.
Nessuno ti vieta di usare anche cinque campi varchar per una chiave ...
auguri con lr query, però, e con il debug a posteriori.
ciao, f.
ciao, f.


quello che scrivi a mio avviso non ha senso "logico", se per farti un 
esempio banale ma reale
in un assicurazione la chiave è il numero di polizza (alfanumerico), in 
una banca la chiave è il numero di CC (alfanumerico), per l'azienda che 
gestige l'elettricità (acea a roma) la chiave è il numero di contratto 
(alfanumerico) e ennemila esempi dove nella realtà la CHIAVE (cioè 
quell'elemento di unicità che individua, una persona, un rapporto, un 
bene, un servizio, insomma un qualcosa) è ALFANUMERICA se non 
addirittura formato da una serie di campi, perchè a questo punto 
aggiungere un "contatore" numerico per fare cosa???, che senso "logico" 
ha???
non dirmi di trasparenza nelle query, perchè tanto non leggerai MAI con 
la chiave numerica SE la chiave più logica è alfanumerica.
nelle query se l'univocità di qualcosa è formata da un campo 
alfanumerico (chiave), comunque anche inserendo una chiave numerica, 
DOVRAI mettere nelle WHERE condition il campo alfanumerico.
Ciao

 "idQualcheCosa" rigorosamente intero lungo.
anche io, e quoto tutto il resto.

 "idQualcheCosa" rigorosamente intero lungo.
Idem. All'inizio pensavo che fosse uno spreco. Con il tempo ho imparato che le
specifiche possono cambiare e le strutture con loro. Una chiave id numerica
autoincrementale "al di fuori" dei dati e' piu' comoda.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
A Smith and Wesson beats four aces.

 autoincrementale "al di fuori" dei dati e' piu' comoda.
E due ;)
ciao, f.