Newsgroup: it.comp.appl.access
Titolo: [OT] campo contatore

Scusate ma rimango perplesso per quanto riguarda il campo contatore che
alcuni di Voi ritengono fastidioso e desidererei avere alcune delucidazioni:
in mancanza di un campo contatore in quale altro modo potrei realizzare un
db con eventuali relazioni evitando di implementare lo stesso db con dati
ripetuti all'infinito?
Grazie per ogni eventuale tipo di consiglio

 dati ripetuti all'infinito?
Ciao.
Non so a cosa ti riferisci in particolare, comunque io posso dirti che i 
campi contatore sono una manna dal celo :-)
Io li uso sempre, in qualsiasi tabella, come chiave primaria. Ovviamente 
sono coinvolti pesantemente anche nelle relazioni, e questo secondo me č 
un bene, vista la garanzia che Access da relativamente ai campi contatore: 
valori sempre univoci all'interno della stessa tabella.
Quello che semmai io vedo sbagliato č l'utilizzo dei campi contatore per, 
ad esempio, utilizzarli come numero fattura: non nascono per quello e non 
capisco cosa ci sia di complicato nell'utilizzare un proprio campo numerico 
gestito a parte (e questa problematica č stata discussa anche di recente).
Conclusione: usa sempre i campi contatore, ma sempre per quello che sono, 
senza cercare di stravolgere il loro ruolo.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution


Chiedo scusa ma a questo punto credo di vare capito male io e pensavo di 
sbagliare poiché utilizzo sempre i campi contatori come chiave primaria di 
ogni tabella e quindi nelle relazioni!
Grazie

 Grazie
Concordo appieno con Gabriele, se poi, tutte le volte che è possibile,
li usi come chiave primaria relazionata, sono addirittura il cacio sui 
maccheroni.
Bruno 


sono io che li "aborro". Forse unico e' solo ma citando un poeta (ohh e' 
una citazione ) "quale *grande* si e' mai scelto la strada piu' breve e 
piu' facile...."
Vuoi un esempio?
Prendi una anagrafica qualsiasi in cui hai il codfisc come chiave 
univoca (saranno pure 16 bytes ma che fa?). Ora spiegami (spiegatemi) 
per quale diavolo di motivo mi devo generare un contatore che tra 
l'altro mi consente di "buttare" dentro anche dei codfisc duplicati.
Prendi una vettura. Per quale motivo ti devi generare un contatore 
quando hai la targa (e' vero che le targhe si perdono pero'....si pone 
rimedio) e se ne devi gestire i consumi ogni volta join perche' hai 
spesso bisogno della targa.
prendi un impiegato che ha una sua matricola per quale diavolo di motivo 
mi devo generare un counter, uso la matricola.
Se poi ha la parte stipendi da relazionare (e spesso ti serve la 
matricola) in questo caso non devi neanche fare la join.
Come cantava zucchero "non vi sopporto piu' davvero...."
--
ac


come puoi vedere dalla mia risposta a Giuseppe. Dissento fortemente e 
fermamente. I counters sevono quando non si ha alcuna altra chiave 
candidata. Saro' "vecchio" ma fino ad un po' di tempo fa (quando si 
doveva risparmiare sul bit) di counters neanche l'ombra
--
ac

 Grazie
Celio. Spero che non mi capitino mai tuoi db da manutenere. ;<)
--
ac

 piu' facile...."
prima che mi rompete i "cabbasisi"
errata corrige
..unico e solo..
--
ac

 matricola) in questo caso non devi neanche fare la join.
Nei tre esempi che hai fatto sarebbe assolutamente fuori luogo,
una forzatura senza utilità, usare un AutoNumber.
Non è proprio a quella maniera che va usato.
Ma prendi un elenco clienti, perché non generare un AutoNumber
PrimaryKey da usare come lato UNO in una relazione
Uno-a-Molti con la tabella fatture, con quella movimenti di PD, etc?
Ovvero tutte le volte che necessiti di una numerazione a valori unici
(libri contabili, etc)...
Penso potrei fare tanti esempi di buon utilizzo di un
AutoNumber quanti ne puoi fare tu di un cattivo utilizzo.
Bruno

 (libri contabili, etc)...
ciao Bruno.
mi cito "....quando non hai una chiave candidata..."
In questi casi potresti non averla.
PD? Intendi il Piano dei Conti (PDC)? In questo caso il codice che 
preferisco e' quello di conto. Righe di prima nota (libro giornale)? Ma 
una volta non dovevano essere senza "buchi"? E' difficile avere un 
Counter senza "buchi".
Che poi se non ci fosse lo si dovrebbe inventare puo' essere un'altra 
storia. Parecchi anni fa ne ho sentita la necessita' non avendoli a 
disposizione. La loro mancanza mi obbligava a continue riorganizzazione 
dei datasets  e parlo di roba parecchio voluminosa (su mainframes IBM e 
metodo di accesso nomato VSAM)
--
ac

 alcuni di Voi ritengono fastidioso e desidererei avere alcune
delucidazioni:
Probabilmente hai frainteso il contesto.
Ciao, Simone

 doveva risparmiare sul bit) di counters neanche l'ombra
E' ovvio che se una chiave primaria č gia "intrinsecamente" definita in una
tabella non ha senso usare un counter (ad esempio il codice pagamento, in
una tabella Pagamenti č giů una chiave univoca).
Ma rinunciare ad autonumber(s) per normalizzare tabelle relative a
"movimenti" (testate e righe fatture, primanota, etc) č quantomeno
masochistico.
Ciao, Simone

 ac
Daniele 

 senza "buchi".
Per un piano dei conti è escluso che si possa usare un AutoNumber,
sono d'accordo.
Per PD intendevo registrazioni in Partita Doppia.
Nei libri contabili non vi è obbligatorietà di numerazione
progressiva se non per i documenti emessi, non per la loro
registrazione.
E i "buchi" non ammessi sono le righe lasciate in bianco e non altro.
Ciao
Bruno