Newsgroup: it.comp.appl.access
Titolo: è pratica una chiave primaria composta da due campi

Non avendo grande esperienza di access, ho il dubbio,  se sia semplice da
gestire una chiave siffatta.
In una tabella Corsi, l'insieme dei campi: anno+specializzazione è unico
nella tabella.
In teoria quindi è candidata a divenire chiave primaria. Prudentemente però
ho definito un campo ID di tipo contatore che non ha alcun significato se
non quello di costituire un riferimento univoco.
Il dubbio che mi prende è che nelle varie altre tabelle, come chiave
esterna, riporterò questo ID che non significa nulla, perché penso non sia
tanto agevole riportare due campi (penso ai casi dei campi di ricerca (in
cui la colonna legata è solo una), alle situazioni scheda sottoscheda, ecc.
Dove posso leggere qualcosa su questo problema?
E voi cosa mi consigliereste?
-- 
saluti
Giuseppe
per risposte in privato togli:
LevamiNoSpam
dall'indirizzo.

 dall'indirizzo.
Questo non è il caso...
MAssimiliano

 wrote in message
news:bjk31h$jbs$
1...@lacerta.tiscalinet.it

Hai centrato il problema....!
La comodità in questo caso è relativa, ciò che giustamente
ti deve allertare è l'eventuale difficoltà nella corretta
gestione delle PrimaryKey.
Ovvio che con Id_Counter tutto è più semplice, ma in quanto
a intuitivo.......lascia molto a desiderare.
Io molte volte preferisco le Key parlanti, e ti faccio
un'esempio banalissimo:
CODICE_FISCALE oppure
PARTITA_IVA oppure...
CAP
Credo che in certi casi sia assurdo rinunciare al Campo_Parlante,
da non confondere con il "Grillo".....!
Quello al quale vai incontro è sicuramente unapiù spinta gestione
errori nella fase di salvataggio dati, in quanto essendo 2 o più
i Campi che compongono la PrimaryKey e non essendo AUTOINCREMENTANTI
hai maggiori possibilità di conflitti.
DOVE PUOI LEGGERE A RIGUARDO.....???
Qualsiasi libro di DATABASE, non solo ACCESS, ma DATABASE in genere
spiega come primo argomento la NORMALIZZAZIONE DATI riassunta poche
regole fondamentali.
Ciao.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


Scusa Ale con il riefrimento all'id è vero che non mi significa nulla come
tabella ma come query con la tabella a cui si riferisce è presto fatto e non
ho mille altri problemi
MAssimiliano

 MAssimiliano
Infatti non ho detto che sia a priori sbagliato, solo che
in alcuni casi va valutato.
C'è da dire che l'indicizzazione delle tabelle e quindi la
velocità di accesso ai dati ne ha sicuramente un vantaggio,
in quanto se non ricordo male il tempo di accesso ad una variabile
LONG piuttosto che stringa è differente.
Quello che intendevo è che in tabelle come l'elenco Telefonico
o meglio l'elenco ANAGRAFICO, è cosa opinabile(secondo me no)
l'utilizzo di una Primary_Key numerica, in quanto l'unica vera
Primary_Key è il Codice_Fiscale ed in questo caso è d'obbligo
che debba essere UNIVOCO.
Quello che proponi invece mi obbligherebbe ad avere un ID_Progressivo,
ma non è sufficiente, devo verificare ad ogni inserimento la presenza di
un Doppione sul
codice anagrafico, o con Routine o con l'eventuale Intercettazione
dell'errore di duplicazione Primary_Key.
Rendendolo PrimaryKey non devi complicarti la vita lo fa ACCESS o
SQL_Server.
Poi a livello contabile o fiscale o di Finanza non sò se ci siano
vincoli sulla rintracciabilità dei dati in qualsiasi momento.....!
Sono considerazioni puramente personali, non sono Dettami rigidi.
Poi sai meglio di me che di fatto la standardizzazione del pensiero
riguardo le Primary_Key è cosa dibattuta da anni....!


Vi ringrazio per i contributi perň vi vorrei richiamare al problema
originario.
Mi stanno bene tutte le considerazioni da voi fatte ma il problema ripeto č:
č comoda la gestione di due campi come pk ?
Massimiliano mi ha dato la sua opinione.
La stessa cosa la solleciterei ad altri.
-- 
saluti
Giuseppe

 wrote in message
news:bjkp3a$1ca$
1...@lacerta.tiscalinet.it

Credo che se rileggi bene i post sia ben CHIARO
il concetto.
Se poi non č cosě......BEH...........!


 il concetto.
alludevo ad es. a situazioni in cui attraverso una casella combinata scegli
un chiave esterna e la butti in un campo .
adesso di chiavi ne devi scegliere due e riversarle in due campi!
da questo punto di vista una chiave su un solo campo ha i suoi vantaggi in
semplicità anche se in tab introduci un campo in più che non significa
nulla.
spero di essere stato + chiaro (oggi non ne azzecco una)
:-))
-- 
saluti
Giuseppe

 wrote in message
news:bjkqdd$34q$
1...@lacerta.tiscalinet.it

Sei stato chiaro, ma ti sei anche risposto da solo.......!
La tua valutazione è corretta, come comodità.
Purtroppo non sempre ciò che è comodo è bello.......!
Insomma se il tuo problema era della Combo OK, ma siccome
la tua domanda era GENERICA, non posso dirti genericamente
SI.
Sono stato CHIARO....!!!
