Newsgroup: it.comp.software.database
Titolo: scelta della Primary Key

ciao,
devo disegnare un db per persistere i dati di un modello scritto in java.
Il modello prevede un'entità MACHINES con questi attributi:
nome
marca
modello
etc...
Ho creato una tabella per memorizzare le MACHINES, con una colonna per 
attributo.
Siccome non possono (e non devono) esistere due machines con lo stesso 
"nome", cioè la colonna "nome" è UNIQUE,
mi chiedevo se è necessario e/o raccomandabile creare comunque un 
campo/colonna aggiuntivo "ID_MACHINE" per identificare la machine e creare 
su questo una primary key. Sennò la primary key potrebbe essere direttamente 
la colonna "nome".
Opinioni ?
ciao e grazie per ogni possibile consiglio!

 Opinioni ?
Le opinioni sono no, ni, si, dipende a chi lo chiedi.
Il modello relazionale invece è chiaro: usare solo valori
dallo schema concettuale (la "realtà").
bye

 dallo schema concettuale (la "realtà").
quindi deduco che la tua opinione è no? :-)

 
Talvolta la realtà è poco efficiente visto che i modi che abbiamo per 
simularla sono fondati su modelli che necessariamente tengono conto 
della limitatezza dei supporti tecnologici.
Nel caso in questione se ci sono altre tabelle che hanno relazioni con 
MACHINES mi sembreremme raccomandabile mettere la chiave primaria su 
"nome" e creare anche ID_MACHINES numerico autoincrementato a cui 
collegare le altre tabelle giacchè la ricerca sui numeri è assai più 
veloce che non sui campi testo. Inoltre le tabelle collegate sarebbero 
più piccole, salvando anche spazio su disco.
Tuttavia se non ci sono altre tabelle e la ricerca la fa su "nome" l'id 
numerico non serve a niente.
Ciao, hth

 quindi deduco che la tua opinione è no? :-)
Esatto, ma rilevo che in questo caso si tratta più di programmazione
che di data modeling (ma forse un giorno il tutto verrà unito
in una magica armonia universale... yeah).
bye

 in una magica armonia universale... yeah).
a volte il confine tra i due aspetti è poco marcato oppure capita come credo 
in questo caso che si deve necessariamente avere un piede da una parte del 
confine e un piede dall'altra :-)
A livello di programmazione non cambia molto avere un ID_MACHINE piuttosto 
che lavorare direttamente col NOME.
Avendo definito che NOME è univoco naturalmente! (cioè "unique" sul 
database).
L'ID può avere senso quando è usato in altre tabelle come foreign key (come 
capita anche in questo caso infatti)
Qui giustamente come dice HTH nell'altro reply, se le ricerche le faccio sul 
nome non serve avere l'ID....
D'altro canto potrei usare il NOME come foreign key nelle altre tabelle, no? 
:)
Mi sembrerebbe inutile infatti, in quest'ultimo caso, mantenere un ID 
autoincrement col solo scopo di fare da foreign key... specialmente perchè 
le tabelle collegate non sono molto... saranno una decina!
Più che altro volevo sapere voi come vi regolavate in questi casi, dovendo 
appunto disegnare le varie tabelle per rappresentare uno "schema 
concettuale" e avendo visto nella mia esperienza che quasi sempre viene 
usato un ID numerico come chiave primaria in aggiunta a eventuali nomi 
univoci :-)
grazie!

 è assai più veloce che non sui campi testo.
L'ID non porta alcuna informazione (non è un "datum", lat. dare,
portatore di informazioni). La prima cosa che bisogna fare pertanto è
un join in più per recuperare il "significato" dell'id.
Dato che l'ID autoincrementa in maniera indipendente da Nomi, si
perde una caratteristica molto importante di un indice, la
"localizzazione" di un indice (es. indice cluster su nomi), col
risultato che un range scan e i merge join saranno compromessi; cosa
ancor più problematica dato che senza i join non recuperi il
significato di un ID. Come risultato query optimizer potra scegliere
di fare una scansione completa anche in presenza dell'indice!
Pertanto la tua implementazione ha due indici scarsamente utili +
una colonna + un extra join come zavorra iniziale, sotto l'assunto
che ciò sarà più veloce. A questo punto, prima ancora di vedere
un esempio, ti chiedo se ne sei ancora così sicuro.
Oltre al fatto che avrai un bel da fare per dimostrarlo, ti faccio
notare che ora lo schema è irrimediabilmente compromesso da elementi
estranei, oltre che "ottimizzato" nei confronti di una specifica
architettura e/o query. Il modello relazionale invece è il più
generale.
Hai aperto il messaggio dicendo che la realtà viene influenzata
dallo strumento usato per misurarla: avevi ragione.
Infatti il risultato è che non soltanto il db non è più uno
specchio fedele della realtà, ma è del tutto probabile che fallisca
proprio lo scopo per cui è stata così implementata, ossia la velocità!
bye

 una decina!
Infatti: sono considerazioni pratiche che si possono presentare in
uno schema ma non in un altro; oppure possono essere irrilevanti se
la mole di dati è modesta ed è più importante la praticità etc etc.
Non si possono dare regole generali in questo caso, dato che è
coinvolto solo il programma ed il db; molto dipende da quanto
bene il tutto è incapsulato e cosa succede se devo fare dei
cambiamenti: se è una cosa solo tra me il db, allora il tutto è
meno importante (ma già se si lavora in team può essere diverso..)
bye

 ciao e grazie per ogni possibile consiglio!
ciao
gmax
-- 
 _  _ _  _
(_|| | |(_|><  The Data Charmer
 _|
http://datacharmer.org/

 
bye

 implementazioni non rispecchiano fedelmente i modelli.
Chiaramente il dolcetto arriva alla fine.
bye

 copia a grandezza naturale di tutti i pianeti che incontrava.
cartografia 1:1 di borges.
ciao, a.

 cartografia 1:1 di borges.
Insufficiente: deve essere "così com'è" (rilievi, odori, temperature etc).

 Insufficiente: deve essere "cosě com'č" (rilievi, odori, temperature etc).
:)
grazie, mi risollevi da una giornata di m.
ciao, a.
certo, gia' e' dura blobbare le immagini. gli odori...

Beh, mi hai fatto cambiare idea sull'uso indiscriminato degli id numerici.
Tuttavia a voler essere pignoli l'id numerico è ridondante ma non come 
dici tu "non reale". Nel momento in cui lo usi è realissimo. Anche il 
nome di una persona è giusto un artificio.
C'è un motivo che mi spinge ad odiare l'uso delle stringhe come chiavi 
primarie e sta nel fatto che sebbene possano svolgere questo lavoro 
quando considerate come sequenza di caratteri non possono farlo dal 
punto di vista semantico. Per un computer le stringhe "Roma" e "Capitale 
d'italia" sono diverse ma per un essere umano sono la stessa cosa. 
Peggio ancora se consideriamo "Paolo Rossi" con "paolo rossi" oppure 
"emilia romagna" con "emiglia romagna" oppure "AC/DC" con "AC-DC" ecc. 
ecc. Quindi personalmente preferisco evitare le stringhe come primary 
key a meno che non si tratti di codici tipo il codice fiscale.
Inoltre considera che molti siti che trattano il tuning spiegano che è 
sempre meglio effetuare ricerche su campi numerici che su campi stringa.
Per inteso il caso delle machines potrebbe non aver niente a che fare 
con tutto questo.

vi ringrazio tutti per i preziosi consigli e l'interessante discussione :-)
nel caso specifico delle machines, svelo il mistero, il nome della machine 
non è altro che un nome DNS (domain name system), quindi ci pensa qualcun 
altro a garantirmene l'univocità, e dal mio punto di vista può essere 
benissimo una chiave primaria :-))

 a meno che non si tratti di codici tipo il codice fiscale.
A parte che con i numeri posso avere concettualmente gli stessi
problemi (vedi esempio delle temperature), qui rilevo una
contraddizione: che cos'ha di speciale il CF che dici lui si e gli
altri no? Per caso, è una BUONA CHIAVE PRIMARIA? (si)
E questo ha a che fare col fatto che sia una stringa? (no)
Anche il CF può essere inserito con maiuscole, minuscole, o in
maniera mista se l'operatore fa casino; sta al db avere un solo dato
a fronte di più rappresentazioni.
bye

 
ciao

 vedi uno username che altro non è che una invenzione presa sul momento?
Ti ripeto che non ci riferiamo al "vedere" in senso fisico, ma
alla corrispondenza con lo schema concettuale.
Il resto del tuo messaggio ha a che fare con riconoscimento
(=algoritmi) del linguaggio, cosa molto diversa da un modello di dati.
bye

 sembra funzionare bene :)
Peraltro le equazioni differenziali relative alla concatenazione dei 
campi elettro magnetici (onde elettro-magnetiche) fu individuata da 
Maxwell elaborando un modello.
--
Avrete anche voi visto camminare le aquile
F. Battiato

 Avrete anche voi visto camminare le aquile
quante cose che m'hai fatto ricordare con sta sign ....
grazie
[mi scuoa per l'OT]