Newsgroup: it.comp.appl.access
Titolo: valori univoci: contatore o chiave personalizzata?

Ciao a tutti, per una volta scriviamo un messaggio a quattro mani ... ebbene 
si il ciroteo è venuto a trovarmi nel mio ufficio!
Dopo aver deciso il colore delle tende, ci stavamo ponendo una questione 
meno seria.
E' più opportuno, in termini di normalizzazione e di scalabilità, utilizzare 
nelle tabelle sempre e comunque un campo IDcontatore anche se altri campi 
possono avere valore univoco?
P.e. in  una semplice anagrafica il codice fiscale potrebbe essere chiave 
primaria o campo indicizzato con ammessi solo valori univoci.
Quale delle due soluzioni è preferibile in termni di performance e 
scalabilità?
Nello specifico abbiamo diverse tabelle (tbl_prodotti : nomeprodotto, 
tbl_tipologia_ di_supporto: nome tipologia, colore ecc..) che potrebbero 
avere un solo campo con valore univoco, e quindi non abbiamo utilizzato la 
chiave primaria contatore.
ciao e grazie
Mariolo e ciroteo ... just married! 

 Mariolo e ciroteo ... just married!
non sbandarmelo in questo periodo, anche perchè vorrei mangiare i confessi
rossi prima di quelli bianchi!!!
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 scalabilità?
Discorso ampio e articolato
Diciamo che se una tabella  già contiene un campo univoco è logico
utilizzare quello come chiave primaria.
Sebbene in molte applicazioni di DataBase non sia così frequente avere
tabelle con campi univoci: supponi che la tua anagrafica articoli contenga
un campo CodiceAzienda (nel contesto di una logica multiditta) ... a quel
punto il CodiceArticolo da solo non assicura univocità.
In tal caso hai due soluzioni:
1) Aggiungi un autonumber
2) Crei una chiave alfanumerica multicampo costituita da CodiceAzienda +
CodiceArticolo.
Vantaggi soluzione 1):
Il motore di DataBase deve mantenere un file indice più piccolo ed
efficiente (Intero Lungo) rispetto alla soluzione basata su chiavi
multicampo.
Non ci si deve preoccupare di conflitti di assegnazione di chiave,
soprattutto in ambiente multiutente: è tutto a carico del motore di
database.
E' una soluzione semplice e immediata per normalizzare tabelle.
Svantaggi soluzione 1):
Chiavi numeriche non "parlano"  :-)
In caso si debbano scrivere programmi di sincronizzazione DB ci sono più
difficoltà (per quanto non insormontabili).
Non tutti i Server di DataBase supportano gli "autonumbers": è un rischio
nel caso di un'applicazione che, in prospettiva, possa essere agganciata ad
altri motori.
Per la verità la connettività verso i Server più diffusi non presenta
problemi con campi a incremento automatico.
Vantaggi soluzione 2):
Le chiavi sono intrinsecamente "parlanti": in varie situazioni la cosa si
apprezza.
E' una soluzione "universale": nessun problema di scalabilità verso altri
motori.
Svantaggi soluzione 2):
Chiavi multicampo allocano, normalmente, molto più spazio su disco rispetto
a indici "Long": in pratica significa tempi di manutenzione più lunghi e DB
più voluminosi.
Tra l'altro nel caso si debbano normalizzare tabelle, si dovranno prevedere
indici multicampo "esterni" da legare a quelli della tabella Padre.
La complessità di sviluppo aumenta, su vari fronti: da una semplice
FindFirst utilizzata da VB ai controlli da operare in fase di scrittura
records per evitare conflitti da duplicazione chiave.
Analizzati pro e contro, decidete voi  :-)

 più voluminosi.
Sono d'accordo con quello che dici. Per quanto riguarda invece il 
quotato, pur essendo inconfutabile quello che riporti, terrei conto del 
dettaglio che la definizione degli indici e' una scelta non cosi' semplice.
1) ritengo inutile definire una PK (counter o meno) se poi non la si usa
2) Se la chiave e' utile (controllo univocita' valore e gestione 
integrita' o accessi frequenti per quel/quegli attributi)  e' necessario 
indicizzarla e quindi ci troveremmo a dover comunque definire un indice.
3) Rispetto all'utilizzo dello spazio. L'impiego di un indice o meno 
dovrebbe essere funzione del tipo di applicazione:
  a) Data Entry? no party (nessun indice)
  b) Vagonate di select? Indici sugli attributi di filtro
  c) Mass insert seguite da select? .1 Drop Indexes .2 CompactDB .3 Mass 
insert .4 Index rebuild
Proprio per i motivi che elencavi riguardo alla compatibilita' con altri 
DB ed alla difficolta' in presenza di relazioni di "riconoscere" gli 
elementi relazionati "aborro" l'uso dei counter. Trovo che non abbia 
senso, che so, definire una tabella province e mettere come chiave un 
counter quando la sigla provincia va piu' che "meglio". Anche in 
considerazione del fatto che se uso un counter come chiave devo poi 
controllare o farmi controllare dal DB che non abbia immesso una sigla 
doppia.
--
a.cara


Scusami Oscar, ma spunti per analizzare i pro e i contro dal tuo post non ne
emergono.
Ciao, Sandro.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 emergono.
Non ne emergono perchè non hai capito semplicemente nulla: rileggi meglio il
post e non toccare alcoolici.
Ciao, Oscar

 doppia.
Verissimo: infatti ricade nel discorso "... se una tabella  già contiene un
campo univoco è logico
utilizzare quello come chiave primaria"
Il problema di scelta si pone quando ci sono più tabelle da normalizzare:
nel post
precedente ho fatto un esempio abbastanza particolare (CodiceDitta +
CodiceArticolo) che forse avrei dovuto risparmiarmi ... e infatti ha
favorito le traveggole del Troll più sotto.
Allora parliamo di una casistica che tutti devono affrontare (Sandri o
Pinchi Pallini che siano): l'esempio classico della tabella TestataDocumento
e RigheDocumento...
Usando un campo identity la normalizzazione è immediata: IDDocumento (long)
come PK
in Testata e FK in RigheDocumento.
Se il campo è un Counter incrementato dal motore di DataBase, ci si dovrà
solo preoccupare che la FK delle righe, in fase di data entry, abbia lo
stesso valore della PK di testata.
Rifiutando il Counter diventa necessario inventarsi una chiave multicampo
per legare TestataDocumento e RigheDocumento (a meno che non si scelga di
utilizzare un Long da incrementare a programma, ma questo è ancora un altro
discorso).
La faccenda si complica: si dovrebbe aggiungere un campo Data/Ora e unirlo
al Codice Cliente per creare una PK univoca (è una delle possibilità, non
l'unica chiaramente).
E qui si ricade nel discorso del post originario (quello che non dice nulla
al già citato Troll): una chiave bicampo come quella descritta è più
pesante rispetto al Long  _e questo influisce in fase di salvataggio dei
records_  e comunque in
ambiente multiutente *reale* richiede codice di controllo per azzerare il
rischio di chiave duplicata.
Inoltre esistono ricadute in fase di programmazione: un FindFirst (per
esempio) dovrà avere due e non un solo criterio di ricerca per individuare
un Record.
Chiavi costituite da 4 o 5 campi (e chi ha lavorato in Cobol le ricorda)
comporterebbero, nell'ambito di un discreto progetto, oneri aggiuntivi di
cui tener conto.
Per contro gli autonumbers presentano i problemi di "anonimato" e,
potenzialmente, scalabilità che discutevo in precedente post.
In conclusione: discorso articolato, con pro e contro.
Ciao, Oscar

 problemi con campi a incremento automatico.
Hai fatto bene a precisare ciò: può darsi esistano ancora Server che non
supportino autonumbers, ma si tratterebbe di una limitazione ormai
preistorica.
E infatti non ci sono problemi d'interfacciamento con in "counters" di SQL
Server, MySQL o InterBase (per fare esempi di motori effettivamente
diffusi).
E non prendertela per i Troll: li trovi ovunque ormai!    ;-)
Cristiano

 post e non toccare alcoolici.
Quando ignoranza e presunzione si sposano nasce Oscar Manfredini.
Sono disgustato. Soprattutto dalla tua maleducazione.


 Sono disgustato. Soprattutto dalla tua maleducazione.
Diciamo che dalla tua risposta parevi un classico Troll con un pò di tempo
libero.
Nel caso le tue intenzioni fossero oneste mi scuso per la risposta (più o
meno) maleducata...
Tuttavia resta il fatto che, per inesperienza o scarsa voglia di leggere:
1) non hai capito quanto ho scritto
Oppure
2) Non hai le idee chiare sulle modalità di normalizzazione degli archivi:
qui non si parla di opinioni, di se e di ma,  ma di "matematica".
Quindi, ti consiglio di leggere meglio il Th, in particolare l'altro post
con l'esempio relativo alla normalizzazione di Testate e Righe Documenti
(forse più chiaro).
Ciao, Oscar

 (forse più chiaro).
L'utilizzo delle chiavi autoincrement dovrebbe essere circoscritto *solo* ai
casi in cui stai tracciando nello spazio o nel tempo una serie di eventi. In
questi casi, infatti, un record di per se stesso non basta a definire in
modo non ambiguo un'istanza di un entità, ma è la coppia
(record,istante/luogo) a rendere significativo e non ambiguo un record.
Prendi il caso del documento nella usuale forma testa/righe. Le righe
*devono* essere marcate da un marcatore posizionale (ad es. il numero di
riga) o qualsiasi altra amenità che possa rendere distinguibili due istanze
di riga. Due righe documento identiche in cosa possono differire se non
nella loro posizione all'interno del documento?
Nei casi anagrafici, invece, se c'è bisogno di un autoincrement per rendere
univoca una entry, beh, allora il problema è mal posto. Ecco perchè, imho (e
lo dico con l'umiltà che mi contraddistinghe da oltre vent'anni di onorata
professione di disegnatore di architetture di sistemi informativi) due
record anagrafici devono essere distinguibili per forza di cose. In caso
contrario verrebbe meno il concetto stesso di "relation".
Ergo, se ciascun record è logicamente distinguibile da un altro, beh, allorà
vorrà dire che rappresenta istanze differenti, e che prima o poi un'istanza
sarà oggetto di ricerca mediante i suoi attributi parlanti, piuttosto che
mediante l'anonimo (cito dal tuo post) id autoincrement.
L'aggiunta forzata di un autoincrement semplifica falsamente lo sviluppo.
Perchè appesantisce inutilmente la maggior parte delle queries.
Provo a schematizzare un esempio:
Articoli:cod_fornitore,codice_articolo,descr_articolo
Movimenti:ID_autoincrement,cod_fornitore,codice_articolo, qty_piu_meno
Se vuoi l'elenco della movimentazione dei codici del fornitore TIZIO
basterà:
SELECT codice_articolo,sum(qty_piu_meno) as movimentato FROM Movimenti
WHERE cod_fornitore='TIZIO'
GROUP BY codice_articolo
Supponi di mettere una chiave autoincrement sugli articoli:
Articoli:ID_autoincrement,cod_fornitore,codice_articolo,descr_articolo
Movimenti:ID_Autoincrement,ID_ARTICOLO,qty_piu_meno
In questo caso la query di sopra diverrebbe
SELECT codice_articolo,sum(qty_piu_meno) as movimentato
FROM movimenti,articoli
WHERE movimenti.ID_ARTICOLO=articoli.ID_autoincrement AND
articoli.cod_fornitore='TIZIO'
GROUP BY codice_articolo
cioè hai introdotto un join che nel caso precedente non hai. E ti assicuro
che su database da trenta o quaranta milioni di record questa differenza, in
termini di prestazioni e peso computazionale, si sente eccome.
Spero di essere stato minimamente chiaro.
Ah, non dirmi che nel caso autoincrement si risparmia spazio per gli indici,
perchè se i dati sono descritti in modo corretto una chiave unica su
fornitore e codice articolo ce la devi mettere sempre e comunque.
;-) (la faccina sorride, per evitarti rovesci di bile)


 ;-) (la faccina sorride, per evitarti rovesci di bile)
Non mi eviti proprio nulla: ribadisco (anche alla luce di questo post) che
l'altro giorno mi hai attaccato gratuitamente, dandomi del fesso in maniera
ingiustificata.
Ciao, Oscar

 ingiustificata.
Non credo di averti mai dato del fesso. Se così è sembrato ti chiedo
pubblicamente scusa. Ma ti chiedo l'intelligenza di rileggere per bene il
post originario, senza preconcetti e senza volerti defendere ad ogni costo.
Ho solo detto una cosa che mi è sembrata ovvia: la questione in subject non
poteva essere liquidata così alla buona. Fra l'altro, anche altri meno
niubbi di me ti hanno fatto notare le medesime cose.
Inoltre stai sorvolando su di un altro aspetto, imho, ancor più importante:
la presunta semplicità del sw lato client in caso di FK numeriche. Come può
il client essere più semplice con gli autonumber?
Se avessi lavorato con MyODBC o MyOLEDB non diresti, a cuor leggero, che con
gli autonumber si semplifica il sw. Anzi, diresti di evitare come la peste
il ricorso agli auto_increment ... ;-)
A questo aggiungici l'aumento di complessità delle selezioni e poi cerca di
sostenere ancora la tesi della semplicità.
Oscar, malintesi a parte è stato un immenso piacere confrontarsi.


 E non prendertela per i Troll: li trovi ovunque ormai! ;-)
Eccone un altro ...


 Oscar, malintesi a parte è stato un immenso piacere confrontarsi.
Ma senti un pò Sandro .... sarai mica SandroBi con nick name modificato
vero?
Ciao, Oscar

 Eccone un altro ...
Spiacente, ma la sensazione era quella.

 ha
scritto:

Se basta una semplice sensazione per classificare una persona vuol dire che
siamo davvero messi male.
Sandro.


 siamo davvero messi male.
Amico mio, sullo Usenet si ricevono solo sensazioni ... e tu non sei un
aficionados di lunga data, con una "gloriosa storia" alle spalle.
E dato che le tue dichiarazioni, nel contesto di questo post, lasciano a
desiderare è stato facile scambiarti per un fomentatore di disordini.
Cristiano

 desiderare è stato facile scambiarti per un fomentatore di disordini.
Sarai anche un aficionado, ma non ho visto alcun tuo reply al mio post, ma
solo quello di Manfredini.
Se hai qualcosa da obiettare in merito a quanto ho scritto, fallo in modo
canonico, quota, rispondi, obietta, rivendica.
Diversamente, astieniti dal dare giudizi di valore sulle persone in modo
gratuito, poichè la cosa non denota ne intelligenza ne saggezza: in pratica
lo stereotipo del lamer.
Io potrò anche aver detto cazzate, ma non ho dato del deficiente a
Manfredini rispondendo al mex di un altro.
Se qualcuno che utilizza OE volesse fare f/up su idl ne sarei grato, visto
che tutto ciò è palesemente OT
Saluti.


 Manfredini rispondendo al mex di un altro.
Mica t'ho dato del deficiente: semplicemente anch'io sulle prime pensavo
fossi un Troll.
Cristiano

 canonico, quota, rispondi, obietta, rivendica.
Ei ragazzi: adesso non cominciate vuoi due eh?   ;-D
Piuttosto Sandro: mi sei debitore ancora di una risposta...
Ciao, Oscar

 Ne d'altra parte ho sostenuto tesi azzardate, mi permetto d'aggiungere!
Per quanto mi riguarda, visto che hai citato il cobol (tra l'altro la 
citazione era leggermete fuorviante), ero abituato a trattare dati 
numerici binari per risparmiare spazio e credo di sapere cosa significa 
"spreco" di spazio.
Qui la questione e' leggermente differente. Ho notato che chi lavora in 
access ha la tendenza ad utilizzare i counter quando non servono 
assolutamente e a definirli chiave primaria assegnandogli spesso una 
valenza che non hanno.Personalmente continuo a preferire le chiavi 
"candidate". Se non le trovo o diventano troppo complesse comincio a 
valutare la possibilita' di inserire un counter, una sequence, un ISN o 
come diavolo lo si possa chiamare.
Che esistano casi in cui la "codifica", non il counter, sia utile e 
certe volte indispensabile e' un fatto che e' talmente evidente che mi 
sembra superfluo discuterne.
Che la lunghezza della chiave sia un parametro importante nella 
valutazione dello spazio necessario per gli indici e' un altro fatto di 
cui l'evidenza e' accertata, sebbene, per questa situazione, 
bisognerebbe conoscere in modo adeguato l'"internal" di ciascun dbms per 
capire, sia come vengono generati e strutturati gli indici, sia come si 
evolvono ed il "degrado" che subiscono in seguito alla operativita' del 
sistema. Su questo, quando lavoravo sui file VSAM-KSDS, (hai citato il 
Cobol e la P.A. quindi puo' darsi che tu sappia cosa sono), ho fatto 
diversi esperimenti tra cui anche inventarmi il "counter".
Come tutte le cose non esiste il pro ed il contro assoluto. Se ci 
limitassimo a valutare le cose in termine di risparmio di spazio tutta 
quella "manfrina" che va sotto il nome di datawarehouse non avrebbe mai 
avuto ragione di esistere.
Normalmente cio' che guadagni da una parte la perdi da un'altra.
Risparmi spazio per un'indice? Magari ne devi creare un altro che 
altrimenti non ci sarebbe stato, oppure hai bisogno di macchine con ram 
e cache spropositata per far si che join, altrimenti non necessarie, 
possano avere dei tempi di risposta accettabili.
Tutto questo riporta poi alla Normalizzazione dei db. Fatto salvo che 
le prime 3 regole (le altre nemmeno le conosco) andrebbero comunque 
applicate se qualcuno si e' inventato il termine -denormalizzazione- una 
ragione deve pur esserci
In definitiva: a morte i counters e tutti i loro profeti ;<)
--
a.cara

"Oscar Manfredini" <osca...@XXX.it> ha scritto nel messaggio
news:igfwe.26646$yM4.4...@twister2.libero.it...

Ciao Oscar,
in questo NG postano due persone con lo stesso Nick, uno sono io Sandro,
l'altro è il Sandro che è intervenuto finora in questo 3D. La differenza la
puoi desumere dal modo diverso di "criptare" l'indirizzo mail.
Sai perchè te lo dico e sono intervenuto in questo 3d con questa
precisazione ? Perchè un po' di tempo fa c'è stata una discussione un po'
accessa, diciamo così tra Sandro ( quello che finora  intervenuto in questo
3D, non io che ti sto scrivendo ... adesso mi incasino anch'io ;-). Un altro
frequentatore che conosce la mia mail personale si è un po' meravigliato dal
tono dei mei interventi e mi ha invitato, visto che mi conosce, a
contenermi.
Ma non erano i miei ma quelli del Sandro che ha postato finora. E comunque
io posto solo su ICAA e su MPIOA.
Io esordisco sempre con un Ciao + nick nome del frequentatore a cui ripondo.
Infatti pensavo di modificare il mio nick, io sono sempre solito stare alla
larga da discussioni che inevitabilmente degenerano.
Sandro se vedi questo post dimmi come la pensi sul fatto di identificarci
meglio.
Ciao Oscar, Sandro.

 In definitiva: a morte i counters e tutti i loro profeti ;<)
Come ampiamente dibattuto in precedenti post: semplicemente ci sono pro e
contro.
Situazioni in cui l'utilizzo dei Counters è inutile, altre in cui è
oggettivamente consigliabile utilizzarli (come d'altra parte tu stesso più
sopra hai dichiarato).
Ciao, Oscar

 meglio.
Beh, è il minimo che possa capitare considerando la *scarsa* diffusione del
vostro nome!
Al posto tuo indicherei il cognome oltre al nome  :-)


Ciao Oscar,
č stato proprio per questo che avevo scelto il mio nome come nick, ma la
legge di Murphy č sempre in agguato !
Ma come mai quella domanda allora ? Vi conoscete per esservi incontrati in
altri NG ?

 altri NG ?
Secondo me hai frainteso il senso di una domanda rivolta a Sandro +
Cristiano...
Vabbè, comunque sia: cambia il tuo nick!     :-)
Manca solo che anche Alessandro Cara dia una potatura al suo e siamo a
posto!
Ciao, Oscar

 meglio.
Ok.
Io navigo su tutt'altri fronti di Usenet e mi firmo sempre con nome e
cognome. Da questo momento in poi firmerò i mex con Sandro Binetti.
Mi scuso per aver generato, mio malgrado, questa confusione ;-)
Ciao, Sandro.


 Piuttosto Sandro: mi sei debitore ancora di una risposta...
Orpo! Seguire un 3d da Arianna č piuttosto complicato. Mi son perso
quaccheccosa? A quale domanda non ho risposto?
Ciao, Sandro.


 Inviato via 
http://arianna.libero.it/usenet/
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it

 Considera che il tuo clone è stato fornato
ops fortunato!!!
devo cambiare la tastiera assolutamente!!!


 rossi prima di quelli bianchi!!!
Il 4 luglio si laurea: che bravo ragazzo, sono orgoglioso di lui!!
Ciao
Mario 

 Mario


Spero che stamattina gli animi siano piů lieti
Dopo aver letto tutto ho capito qualcosina in piů e di questo vi ringrazio 
come al solito
Ho replicato al post di MA del 23, perchč mi rimangono dei dubbi
Se potete rispondete....
Ciao Mario 

 Spagna per coronare il Vs sogno???
Mi sa che andremo a CASABLANCA!
Decideremo a chi ha la pagliuzza più corta. 

 Altro discorso.
Quello che non condivido di questo approccio è che si parta
dall'ottimizzazione piuttosto che dallo scenario. Quando si disegna
un'architettura e si modellano i dati secondo le guidelines relazionali,
ogni record deve differire da un altro per il fatto di descrivere istanze
distinte di un'entità, ed in questo gioco gli autonumbers rientrano *solo*
se si tratta di descrivere delle snapshot di stato nel tempo o nello spazio.
In linea di principio basterebbe anche un timestamp sufficientemente
granulare a rendere univoca un'istanza, ma non come artificio, ma perchè è
l'istanza stessa che diventa significativa nel momento in cui accade dopo la
precedente e prima della successiva.
Mi sono spiegato?
Un architetto che voglia avvicinarsi al disegno di un database dovrebbe
partire dalla percezione netta di *cosa* renda realmente distinte due
istanze di un'entità, perchè da ciò deriva la corretta scelta degli
attributi che occorrono per descriverla.
Insomma, ne faccio una questione di metodo. Perchè è il metodo che, imho, fa
la differenza fra il professionista (informatico) serio e l'improvvisato. E
di improvvisati, credimi (e soprattutto non fraintendere, perchè non penso
certamente a te ed a nessuno altro degli ottimi personaggi che popolano
questo bel ng) ne è piena la piazza.
Ciao, Sandro.


 Decideremo a chi ha la pagliuzza più corta.
o il p.. più lungo ... ! 

 quaccheccosa? A quale domanda non ho risposto?
Mi riferisco al post del     27 Jun 2005    16:42:33
Quello che termina con: "ma sarai mica SandroBi vero"?    :-)
Ciao, Oscar

 questo bel ng) ne è piena la piazza.
Sarà senz'altro così, ma è un discorso che non riguarda direttamente
l'oggetto di questo Th.
Ciao, Oscar

 Ciao, Sandro.
Ciao, Sandro.