Newsgroup: it.comp.appl.access
Titolo: scuola di pensiero sulle primary keys

ciao
sto cercando di fare il punto sulle primary keys e vorrei confrontarmi anche
con la vostra esperienza
per prima cosa, nell'ottica di uniformare i miei lavori, ho sempre cercato,
fino a che era possibile, di non usare pk costituiti da più di un campo: è
buona cosa?
Inoltre ho sempre usato chiavi autogeneranti (per un breve periodo ho anche
usato chiavi casuali, ma ho subito abbandonato per tornare a quelle
autoincrementali) ma sono un paio di giorni che ci sto pensando e mi sa che
non è una gran mossa!
E' vero che il tipo di campo "contatore" è più facile da usare.. ma alla
lunga pone maggiori limitazioni e problemi specie nel caso di frequenti
import/export dei dati da e verso altri db.
Ma a parte questi casi.. nell'uso interno, per esempio nelle maschere e nei
report, nella gestione dei record etc.. che problematiche nascono/muoiono
nell'uno e nell'altro caso?
vale la pena di riprendere in mano i lavori già iniziati per passare a
chiavi generate dall'utente?
1024 grazie

 
dipende dal punto a cui sei arrivato e dalla portata del programma.
se sei all'inizio (struttura e poche maschere), sicuramente ti conviene 
pensare di fare il passaggio.
se invece sei già in fase avanzata, considera quella che sarà la portata 
del progetto: se ti stai facendo una rubrica personale che magari 
passerai a qualche amico, vabbè, ma se stai sviluppando un'applicazione 
su cui si baserà qualche azienda per tutta la movimentazione del 
materiale interno, facci un pensierino...
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
+-------

 la fattura 1 e quindi dovrei aggiungere alla chiave anche l'ano, ma se
vabbè che a volte ci si fa il qlo, ma stavolta m'è solo scappato...


 ha scritto nel messaggio
news:bbl3vi$sn1$1...@grillo.cs.interbusiness.it...

Se si vuole fare solo un po' di filosofia spicciola sulle primary keys
generalizzando allora potrebbe essere utile andare sul Sito Comune (link qui
sotto) e nella Sezione General leggere la FAQ di Emanuele Cesena intitolata
"Cos'è un ID? Contatori, numeri, e altro", nella quale si cerca di
prospettare i prò ed i contro di varie soluzioni.
Penso comunque che molti dilemmi nel progettare un database nascono in
quanto spesso ci si incaponisce di far coincidere la chiave primaria con uno
o più campi codice della tabella: questa è una necessità solo nel caso in
cui il database non è relazionale; in un database relazionale invece la
chiave primaria di una tabella è, per definizione, un oggetto che ha lo
scopo di rendere univoci i record: se alla chiave primaria si lascia
solamente questa funzione, ritengo che possa essere rappresentata da un
campo contatore e non farle avere alcuna funzione nel piano di codifica dei
dati; ad esempio, la chiave primaria di una tabelle fatture potrebbe essere
un contatore, che non coinciderà con il campo numero fattura: questi
risulteranno due campi distinti che nel database hanno funzioni e compiti
sostanzialmente diversi. Ciò non significa che non si possa usare il campo
numero fattura (non contatore) anche come chiave primaria della tabella
fatture, basta valutare, in funzione di come si è disegnata l'architettura
del database, quali siano i pro ed i contro della scelta.
Non credo che esistano soluzioni per la chiave primaria che siano da
privilegiare sempre e comunque rispetto alle altre: bisogna avere chiari in
mente quali siano i pro, i contro ma innzitutto i limiti di ogni soluzione e
quindi scegliere la soluzione più consona al database che si sta
progettando. Un esempio per tutti è la soluzione di Sib pubblicata sul Sito
Comune per la numerazione delle fatture: è talmente valida che viene spesso
consigliata a chi abbia problemi di gestire automaticamente una chiave
progressiva a struttura complessa; quella soluzione però presenta problemi
nel caso si debba operare con la base dati SQL allocata su un server.
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 chiavi generate dall'utente?
Ci  sono pro e contro, come in tutte le cose.
Autonumbers PRO:
- Comodissimi da usare per normalizzare tabelle.
- Gestione interna automatica dell'incremento in mono-multiutenza.
- Interi lunghi, quindi molto compatti a livello d'indice e veloci.
Autonumbers Contro:
- Sono più complesse _forse_ le procedure d'import/Export
- Non sono chiavi "parlanti": il loro contenuto non ti dice nulla sulla
natura del record
Chavi Multicampo PRO:
- Può essere _relativamente_ più semplice scrivere programmi d'import/Export
- Sono chiavi "parlanti"
- E' semplicissimo modificare manualmente (brutto segno quando si senta tale
necessità) il valore della chiave
Chiavi Multicampo Contro:
- Allocano molto spazio su disco (chiave primaria ma anche "esterna") e sono
più lente a livello di gestione.
- La scelta può dar adito a tanti pensamenti e ripensamenti.
- In regime multiutente si deve prevedere del codice che controlli e
gestisca l'eventuale duplicazione.
- Aumenta la complessità di programmazione, pensa a un classico:
Set RstMov=DB.OpenRecordset("Select * from Movimenti where [IDMovimento]=" &
ContMovimento & ";" _
                               , dbOpenDynaset, dbSeeChanges)
Diventa macchinosa se al posto di un autonumber si utilizza una chiave
composta da due o più campi.
Inoltre la rigidità dei "contatori" in fase d'import-Export dev'essere
valutata con attenzione.
Anzitutto con SQL Server puoi togliere e ripristinare a piacimento
l'incremento automatico e smacchinare _conseguentemente_ a piacimento con
gli interi lunghi della chiave primaria, anche a manina.
Con JET c'è maggior rigidità, ma fino a un certo punto: lavorando con
oggetti recordset puoi creare i nuovi records imponendo il valore della
chiave contatore al valore che desideri.
Questo rende possibile la scrittura di algoritmi di "reindirizzamento" dei
contatori ottimi per risolvere le problematiche più rognose d'Import-Export.
Ti saluto.

 molti dati, auguri! :-))
Ciao
Sib

 
pare che con versioni successive alla 97, quando cancelli delle righe e poi 
compatti, il campo contatore ricominci comunque dal valore massimo 
raggiunto prima della cancellazione.
cerca qualche thread sotto, l'aveva detto qualcuno che usa a2k (io uso solo 
il 97...)


 il 97...)
confermo
però se cancelli tutte le righe e poi compatti invece il contatore si
azzara!