una chiave primaria composta da più colonne, è un DAC è vero che "alcuni" db supportano where (tuonome, tuocognome) in (select nome,cognome from anagrafica) ma mica è ANSI standard... e comunque le performance di ricerca su indici compositi non è la stessa di un indice numerico.
questo è il primo di mille motivi sul perché non usare una chiave composta da più colonne: hai dei limiti nell'utilizzo della base dati e le performance sulle join non sono ottimali. inoltre c'è il discorso dell'attendibilità dei dati, che però coinvolge tutte le chiavi, anche quelle singole. Se il dato inserito non è attendibile all 100% è meglio non costruirci una chiave che spalmi in lungo e in largo. e visto che mi è capitato di trovare basi dati con codici fiscali o partite iva sbagliati, direi che nessun dato inserito da un uomo può definirsi attendibile. insomma le chiavi di un db è meglio che non siano accoppiate con il business. i vincoli di unicità si fanno con le unique constraint. punto :-) Se scindiamo il discorso meramente tecnico di mettere in relazione entità diverse da quello che una entità è formata da un certo numero di colonne che ne formano la sua univocità, vedrete che una cosa è dire Simone è il figlio di Luciano e anltra cosa è dire Simone di cognome fa Federici, è nato il... alle ore tot ... il suo codice fiscale etc... tutta roba che identifica univocamente simone ma che non ci azzecca un H con il fatto che Simone ha una relazione di parentela con Luciano. famo a capisse :-) PS. ognuno ha le sue best practice, però alcune sono meglio delle altre.
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
