Newsgroup: it.comp.software.database
Titolo: Mettere o no gli ID nell'ER?

Ciao,
secondo voi è corretto eliminare tutti gli ID dall'ER per includerli solo
nel modello relazionale?
Inoltre, se omettessi tali ID, dovrei usare come chiave primaria..che ne
so..la somma di dati quali nome,cognome,ecc... sottolineandoli tutti?
ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


un cesso :-(
l'id e' la cosa piu sicura (ci possono essere noie ad importare 2 db
identici)


 so..la somma di dati quali nome,cognome,ecc... sottolineandoli tutti?
Domanda annosa, c'e' chi odia e chi ama l'uso di una chiave non naturale 
(cioč generata in qualche modo, come immagino siano gli ID cui fai 
riferimento). Davide Bianchi (che fa parte piů o meno della prima 
schiera) ha scritto un interessante articolo al riguardo sul suo sito, 
ti consiglio di leggerlo
http://www.soft-land.org/cgi-bin/doc.pl?doc=documenti/pk

 
http://www.soft-land.org/cgi-bin/doc.pl?doc=documenti/pk
Lurkare fa sempre bene :)
Articolo davvero molto interessante.
Sinceramente molto spesso ho ritenuto valida l'idea di non usare sempre 
chiavi autogenerate.
Soprattutto ad un mio amico (visto che siamo in argomento) che era alle 
prime armi con la progettazione dei DB (esame universitario) io suggerii 
di usare il codice fiscale (oppure la matricola) come chiave primaria 
della tabella anagrafica per il suo progetto, e quindi di usarla anche 
come chiave esterna per le altre tabelle.
Il motivo per me č quasi vitale: un giorno, dovesse scassarsi il pc o 
danneggarsi il db o qualunque altra cosa, credo sia molto piů semplice 
tentare una ricostruzione umana dei dati partendo da chiavi di quel tipo 
che non da indici numerici.
Questo, ripeto, č solo un esempio. Ma la mia idea č appunto questa: 
usare le chiavi univoche solo quando indispensabile. In altri casi, 
meglio generare a mano dei valori per identificare i record della 
tabella padre.
-- 
Quando noi ignoranti eravamo di piů, tutto era piů bello...
(A. Celentano)
Per rispondermi in privato, prima togli l'immondizia dalla testa.


Io invece consiglio quelle autogenerate.
E per quanto riguarda l'articolo non mi trovo affatto d'accordo.
Esempi del tipo...se per un'errore di progettazione o di implementazione io 
ho inserito un cliente uguale 10 volte..e mi mostra che le chiavi ID lo 
consentono...non é un esempio molto calzante. Primo uno non deve commettere 
errori di progettazione, (se li commentte non c'é chiave naturale o 
autogenerata che tenga...che discorso é mai questo??!)..inoltre se uno vuole 
assicurarsi dell'univocità del cliente metterà un UNIQUE sul campo.
Se uno mette "username" come chiave primaria...e poi l'utente cambia la 
username perché il programma lo consente si modifica tutto il database?Se il 
programma non consente la modifica dell'username molto bene...ma é probabile 
che in un giorno futuro si debba farlo invece. A quel punto sei nei guai.
Poi permette di usare chiave esterne molto piu semplici.
Certo, sono poco umane le chiavi autogenerate...ma i database servono ai 
programmi non agli uomini, altrimenti usi una bella tabella in stile foglio 
elettronico.