Newsgroup: it.comp.lang.visual-basic
Titolo: Una spiegazione sulla chiave primaria

Ciao.
Volevo porvi una domanda per avere un chiarimento.
Ho creato un db con tre campi: Nome - Cognome - Città.
Creo una chiave primaria per i campi Nome e Cognome.
Questo vuol dire che nel mio db esisterà un quarto campo che conterrà un
valore, che sarà determinato sulla base dei valori dei campi Nome e Cognome?
Con quale metodo viene calcolato questo valore?
Grazie e ciao


mi sa che devi fare amicizia col tasto F1, la chiave primaria è un'indice 
che serve per ordinare e avere ove hai bisogno risultati univoci, il nome, o 
il cognome o il numero di telefono possono essere chiavi primarie, ma di 
norma uno usa un contatore numerico autoincrementale come chiave primaria. 
Spero di essere stato chiaro. Altri spero ti spiegheranno meglio. 

 ha scritto nel messaggio 
news:44a1a100$0$3123$4faf...@reader1.news.tin.it...


 valore, che sarà determinato sulla base dei valori dei campi Nome e Cognome?
La chiave primaria serve per identificare in maniera univoca un record.
Sicuramente Nome+Cognome non può essere chiave primaria (ci saranno sempre
due Paolo Rossi), ma neanche Nome+Cognome+Città (due paolo rossi di milano)
lo è.
Quindi o crei un campo contatore progressivo che assegna ad ogni record un
numero univoco, oppure puoi usare ad esempio il Codice Fiscale che è
univoco (o almeno credo).
La cosa migliore è un campo numerico contatore (poi dipende da quello che
devi fare)
-- 
DBMS Firebird
VB6 + Ado

 univoco (o almeno credo).
Anche se viene utilizzato come se lo fosse, in realtà l'algoritmo di
generazione del CF non garantisce l'univocità.
Immagina un tizio che si chiama Gennaro Esposito, nato a Napoli il
01.01.1905.
Poi immagina un suo bisnipotino, che nasce a Napoli il 01.01.2005, a cui
viene dato il nome di Gennaro in onore del bisnonno.
In qs. caso il piccolo Gennariello avrebbe lo stesso CF del bisnonno, e se
fossero vivi entrambi sarebbe un casino.
Io non utilizzerei il CF come chiave primaria, ma non per via di Gennaro e
Gennarino, ma perché non costa veramente nulla aggiungere un campo contatore
in più.
Altrimenti, se vuoi usare dei campi esistenti, devi essere sicuro che la
combinazione dei campi scelti non presenti mai un valore duplicato (es. due
Paolo Rossi di Milano). Se sei sicuro che non ci saranno mai valori
duplicati puoi anche impostare dei campi esistenti come chiave primaria. Ma
ripeto: ad aggiungere un campo contatore (o aggiungere un semplice campo
numerico e controllarne l'inserimento dei valori via codice, in modo che non
vengano mai inseriti valori duplicati) ci vuole veramente poco. Di solito
qs. campo viene chiamato 'campo ID'.
Definizione (uguale, su un sacco di libri): la chiave primaria è quel campo
o quell'insieme di campi che identifica il record in maniera univoca.
Spero ti sia utile. Ciao.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 qs. campo viene chiamato 'campo ID'.
Sono daccordo ed è quello che anche io ho sempre fatto, tranne questo caso
specifico. Anzi a volte ho creato campi ID che di fatto non sono neanche
referenziati ad altre tabelle, ma è "referenziato" magari un
CodiceDescrittivo (nel senso che non c'è una integrità, ma solo che nella
tabella è riportato CodiceDescrittivo e non IDTabella).


 ha scritto nel messaggio 
news:84Z223Z160Z51Y1...@usenet.libero.it...


 fossero vivi entrambi sarebbe un casino.
Guarda qui: 
http://www.comuni.it/servizi/codfisc/
nella pagina del risultato è spiegato come funziona in caso di CF duplicati.
Ciao 

 meglio un autoincrementale.
Beh, è il più utilizzato, un motivo ci sarà. Comunque non è l'unico modo: a
volte le aziende utilizzano dei codici alfanumerici misti e li usano come
chiavi primarie. In tal caso la generazione di un codice univoco va fatta
dal programma (o dal magazziniere, ma questa non è una tecnica che
garantisce un alto livello di sicurezza), ad esempio con criteri
unidirezionali di aggiornamento numerico.
Spero sia utile. Ciao.


 La cosa migliore è un campo numerico contatore
Aggiungo una cosina:
L'autoincrementante (il cosiddetto Identity) è il più comodo, ma non è 
in assoluto la soluzione migliore.
Innanzitutto, esistono istruzioni che consentono di resettare tale 
contatore, andando quindi a generare nuovi valori che duplicherebbero 
valori presenti in passato, con le problematiche di relazione a chiave 
esterna che dovessero provenire da altre tabelle.
E' chiaro che è una cosa brutale, ma nessuno può escludere che un bug 
in un client esegua un TRUNCATE, che appunto resetta il contatore oltre 
a eliminare i record, e se non ci sono vincoli di integrità 
referenziale gestiti dal db, a difendere i record in cancellazione, 
possono aversi relazioni esterne in altre tabelle, che 'muoiono' 
venendo a mancare la PK, quindi non appaiono più in alcuna sleect, poi 
un domani 'risorgono' quando torna ad esserci una PK identica a quella 
tolta in precedenza e che combacia con la FK.
Secondariamente, l'Identity generato può essere ottenuto solamente DOPO 
l'insert, con la necessità, quindi, se occorre utilizzare tale PK come 
FK in altre tabelle, di eseguire ogni volta INSERT e SELECT in 
successione, possibilmente transazionale.
Non che siano problemi insormontabili, tanto che molti non li 
considerano neppure.
Ma esiste un'altra via, che trovo molto comoda: il GUID 
(uniqueidentifier). Esso può essere generato in automatico al momento 
dell'insert, e subito dopo letto come si fa con gli Identity, ma può 
anche essere generato a priori, tenuto lì in una variabile nel client, 
e quindi utilizzato come PK esplicitata nell'insert, e come FK nelle 
tabelle in relazione.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 tabelle in relazione.
Tnx, ora ci do' un occhio.
In ogni caso per il momento ho sviluppato programmi "annuali" e l'uso del
contatore č utilizzato ed anche utile diciamo.
Cioč ho una tabella articoli da richiamare rimane comodo chiamare
l'articolo con ID(contatore)= "130" oppure quello con codice "CocaCola".
Altrimenti bisognerebbe usare questo GUID piů un campo contatore/numerico
per ricercare i vari record. Almeno nei casi che mi sono capitati.


 per ricercare i vari record. Almeno nei casi che mi sono capitati.
Non devi però confondere il codice mnemonico, diciamo così il 'codice 
prodotto', con la chiave primaria della tabella.
La chiave primaria è una colonna che serve per individuare univocamente 
un record, il codice prodotto è una colonna che potrebbe anche essere 
duplicata (ad esempio, potresti avere due record con lo stesso codice 
prodotto, uno 'attivo' e uno 'versione obsoleta').
In linea di principio, nelle anagrafiche c'è la chiave primaria che è 
un Identity o un Guid, e poi ci sono i codici prodotto 'visibili' anche 
all'operatore, che hanno però solo una funzione di ricerca, stampa, 
ecc...
ciao


 ecc...
Intendevo proprio quello, che per i programmi su cui ho lavorato, i campi
chiave contatore sono spesso utilizzati come ricerca, che altrimenti
avviene tramite un codice solitamentee Varchar ("cocacola" appunto).
Ad esempio quando mi ricercano un Nome Rappresentante per nome nella txt,
io faccio la ricerca per ID o Nome a seconda di quello che hanno digitato,
e alla conferma (con eventuale griglia in caso ci siano più record), sulla
Txt dove hanno scritto metto l'id
txtAgente.text=Adors("IDAgente")


 Inviato via 
http://arianna.libero.it/usenet/
Concordo pienamente.
Non ero così informato dei dettagli. Comunque la presenza di stranieri nel 
DB non implica che questi si trovino in Italia e abbiano 
modo/voglia/possibilità di richiedere un codice fiscale... Chiaramente tutto 
dipende dall'applicazione.
Ciao
Elef.