.dsy:it. - Chiavi primarie

.dsy:it. (http://www.dsy.it/forum/)
- Basi di dati ~ informatica triennale (http://www.dsy.it/forum/forumdisplay.php?forumid=211)
-- Chiavi primarie (http://www.dsy.it/forum/showthread.php?threadid=41336)

Posted by Guccio on 15-12-2010 18:59:

Chiavi primarie

Salve a tutti, durante una lezione della Castano mi è sfuggita una cosa. Perchè è preferibile aggiungere un ID come chiave piuttosto che usare un valore della relazione che si sa essere unico?

Posted by CowBoy on 23-12-2010 13:10:

Prova a guardare nelle videolezioni, forse troverai qualche risposta. Probabilmente faceva riferimento ad entità con chiave primaria poco chiara, dove per logica non ci dovrebbero essere tuple ripetute, ma nella pratica servono codici "generici" o valori nulli.

__________________
.. ±·ø·±-`` MuSiC iS My LanGuAGe ´´-±·ø·± ..

Posted by number15 on 05-02-2011 08:56:

Re: Chiavi primarie

Originally posted by Guccio
Salve a tutti, durante una lezione della Castano mi è sfuggita una cosa. Perchè è preferibile aggiungere un ID come chiave piuttosto che usare un valore della relazione che si sa essere unico?

Magari hai già risolto, ma ti rispondo comunque.
E' semplicemente per un discorso di comodità: hai un dato molto più piccolo da portarti in giro.
Es. tabella utente ed usi come chiave primaria 'email' (diciamo varchar(60)).
Ora in ogni tabella in cui devi mettere la chiave esterna su email, devi creare un campo varchar(60) per contenere l'email.
Hai un campo più scomodo da gestire (errori di battitura in caso di data entry manuale, join più pesanti da fare sul varchar).

Conviene quindi creare SEMPRE un campo id_ tipo int unsigned AUTO_INCREMENT (o equivalenti + grandi o + piccoli).

In fase di data entry dovrai semplicemente lasciare quel campo nullo, e ti verrà garantito che ogni nuova tupla sarà unica.

Dovrai poi mettere una chiave unique su email per 'dire' che è una chiave candidata e che quindi non può avere valori duplicati.

Spero di essermi spiegato.
Ciao

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by Guccio on 06-02-2011 12:49:

Spiegato benissimo grazie mille

Posted by lferri469 on 30-03-2011 13:51:

Re: Re: Chiavi primarie

Originally posted by number15
Magari hai già risolto, ma ti rispondo comunque.
E' semplicemente per un discorso di comodità: hai un dato molto più piccolo da portarti in giro.
Es. tabella utente ed usi come chiave primaria 'email' (diciamo varchar(60)).
Ora in ogni tabella in cui devi mettere la chiave esterna su email, devi creare un campo varchar(60) per contenere l'email.
Hai un campo più scomodo da gestire (errori di battitura in caso di data entry manuale, join più pesanti da fare sul varchar).

Conviene quindi creare SEMPRE un campo id_ tipo int unsigned AUTO_INCREMENT (o equivalenti + grandi o + piccoli).

In fase di data entry dovrai semplicemente lasciare quel campo nullo, e ti verrà garantito che ogni nuova tupla sarà unica.

Dovrai poi mettere una chiave unique su email per 'dire' che è una chiave candidata e che quindi non può avere valori duplicati.

Spero di essermi spiegato.
Ciao

ciao number15,
vi volevo chiedere un info perche sono un attimo in crisi

volevo chiedervi nel caso in cui avessi un associazione ternaria nel quale tre entita puntano alla stessa relazione, è possibile piu che possibile dire corretto associare secondo voi l'id di tale relazione (che a livello di sql verrebbe trasformata in tabella contenente le chiavi primarie delle entità) come FOREIGN KEY in una delle entità associate?
non so se mi sono spiegato...
ciao e grazie a tutti

Posted by number15 on 30-03-2011 14:14:

Ciao,
mi posteresti un esempio per capire meglio la situazione?

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by lferri469 on 30-03-2011 15:02:

Originally posted by number15
Ciao,
mi posteresti un esempio per capire meglio la situazione?

ciao number, inanzitutto grazie per avermi risposto.
ti giro l'esempio.
per prima cosa ti vorrei chiedere se secondo te uno schema di questo tipo si possa ritenere corretto anche in presenza di una ciclo...
per qunato riguarda invece la richiesta che ti avevo fatto prima la parte in questione è quella che associa sedi e contratti ad attività.
la relazione works conterra le tre chiavi primarie delle tre entità, ma a livello teorico si potrebbe inserire un id_works come foreing keys in attività?
il mio scopo è quello che dato uno schema er di questo tipo garantire la possibilità di inserire delle attività solo se esiste un contratto o una sede associata.

grazie mille per l aiuto

Posted by number15 on 30-03-2011 17:48:

Cosa intendi per 'inserire delle attività'?
Intendi per esempio poterla scegliere da un elenco?
Se sì, io aggiungere uno/due campi enum in attività del tipo ha_contratto(Y,N), ha_sede(Y,N) (o semplicemente è_selezionabile(Y,N)) che gestisci tramite trigger after insert on works.

Quindi id_works in attività direi che non ha senso.

Ciclo?

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by lferri469 on 31-03-2011 13:51:

Originally posted by number15
Cosa intendi per 'inserire delle attività'?
Intendi per esempio poterla scegliere da un elenco?
Se sì, io aggiungere uno/due campi enum in attività del tipo ha_contratto(Y,N), ha_sede(Y,N) (o semplicemente è_selezionabile(Y,N)) che gestisci tramite trigger after insert on works.

Quindi id_works in attività direi che non ha senso.

Ciclo?

ciao number grazie mille!
per ciclo intendevo quella ciclicità che è presente tra le 4 entità... nel senso se è fattibile creare un modello e/r cosi o oppure no.

All times are GMT. The time now is 08:03.

Show all 9 posts from this thread on one page