Chiavi primarie
Clicca QUI per vedere il messaggio nel forum |
| 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? |
| CowBoy |
| 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. |
| number15 |
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 |
| Guccio |
| Spiegato benissimo grazie mille :) |
| lferri469 |
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 |
| number15 |
Ciao,
mi posteresti un esempio per capire meglio la situazione? |
| lferri469 |
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 |
| 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? |
| lferri469 |
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. |
|
|
|
