Discussione:
valori univoci: contatore o chiave personalizzata?
(troppo vecchio per rispondere)
Mariolo
2005-06-23 15:42:03 UTC
Permalink
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!
MA
2005-06-23 16:00:18 UTC
Permalink
Post by Mariolo
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à?
Ho letto della rinuncia del Skabi...

venendo al problema (e sperando nel vostro buongusto nella scelta delle
tende...)
ti posso dire che in termini i scalarità è sempe preferibile crearsi propri
contatori.
Metti per esempi lavori fuori dalla rete da parte di postazioni portatili
(il rappresentante che va fuori azienda e che crea una ricevuta con un campo
contatore piuttosto che con un contatore che ha un prefisso a lui riferito)
la scelta poi della PK è molto importante e non dovrebbe dare adito a
ripensamenti (conosci i CodFisc di tutti i soggetti?).
Post by Mariolo
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.
Sì magari in questo caso c'è il codice prodotto che funge bene allo scopo
Post by Mariolo
ciao e grazie
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
Mariolo
2005-06-29 08:38:20 UTC
Permalink
Post by MA
Post by Mariolo
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à?
ti posso dire che in termini i scalarità è sempe preferibile crearsi propri
contatori.
Metti per esempi lavori fuori dalla rete da parte di postazioni portatili
(il rappresentante che va fuori azienda e che crea una ricevuta con un campo
contatore piuttosto che con un contatore che ha un prefisso a lui riferito)
la scelta poi della PK è molto importante e non dovrebbe dare adito a
ripensamenti (conosci i CodFisc di tutti i soggetti?).
Post by Mariolo
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.
Sì magari in questo caso c'è il codice prodotto che funge bene allo scopo
Il codice prodotto non c'è però c'è semplicemente la sigla del prodotto che
è univoca.
Secondo te può bastare?
Post by MA
non sbandarmelo in questo periodo, anche perchè vorrei mangiare i confessi
rossi prima di quelli bianchi!!!
Il 4 luglio si laurea: che bravo ragazzo, sono orgoglioso di lui!!

Ciao
Mario
MA
2005-06-29 08:43:04 UTC
Permalink
Post by Mariolo
Post by MA
Post by Mariolo
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à?
ti posso dire che in termini i scalarità è sempe preferibile crearsi propri
contatori.
Metti per esempi lavori fuori dalla rete da parte di postazioni
portatili (il rappresentante che va fuori azienda e che crea una
ricevuta con un campo
contatore piuttosto che con un contatore che ha un prefisso a lui riferito)
la scelta poi della PK è molto importante e non dovrebbe dare adito a
ripensamenti (conosci i CodFisc di tutti i soggetti?).
Post by Mariolo
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.
Sì magari in questo caso c'è il codice prodotto che funge bene allo scopo
Il codice prodotto non c'è però c'è semplicemente la sigla del
prodotto che è univoca.
Secondo te può bastare?
Hai letto quell'articoletto che sto mettendo online?
www.accessgroup.it/negotium.htm ?
Post by Mariolo
Post by MA
non sbandarmelo in questo periodo, anche perchè vorrei mangiare i
confessi rossi prima di quelli bianchi!!!
Il 4 luglio si laurea: che bravo ragazzo, sono orgoglioso di lui!!
ma è vero che ora che ha una posizione avete preventivato un viaggetto in
Spagna per coronare il Vs sogno???
Post by Mariolo
Ciao
Mario
--
_ _
Ciao
MAssimiliano Amendola www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info: www.donkarl.com/it
Mariolo
2005-06-29 09:14:11 UTC
Permalink
Post by MA
Post by Mariolo
Post by MA
Post by Mariolo
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à?
ti posso dire che in termini i scalarità è sempe preferibile crearsi propri
contatori.
Metti per esempi lavori fuori dalla rete da parte di postazioni
portatili (il rappresentante che va fuori azienda e che crea una
ricevuta con un campo
contatore piuttosto che con un contatore che ha un prefisso a lui riferito)
la scelta poi della PK è molto importante e non dovrebbe dare adito a
ripensamenti (conosci i CodFisc di tutti i soggetti?).
Post by Mariolo
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.
Sì magari in questo caso c'è il codice prodotto che funge bene allo scopo
Il codice prodotto non c'è però c'è semplicemente la sigla del
prodotto che è univoca.
Secondo te può bastare?
Hai letto quell'articoletto che sto mettendo online?
www.accessgroup.it/negotium.htm ?
Lo sto tenendo d'occhio...
sicuramente mi servirà quando anch'io dovrò affrontare il magazzino
anche se la mia realtà è più semplice trattandosi di azienda manifatturiera.
Ci sono poche materie prime e pochi prodotti finiti... infatti come ti
dicevo non esistono veri e propri
codici prodotto, ma sigle descrittive.
Penso che comunque si dovrà creare un codice...
Post by MA
Post by Mariolo
Post by MA
non sbandarmelo in questo periodo, anche perchè vorrei mangiare i
confessi rossi prima di quelli bianchi!!!
Il 4 luglio si laurea: che bravo ragazzo, sono orgoglioso di lui!!
ma è vero che ora che ha una posizione avete preventivato un viaggetto in
Spagna per coronare il Vs sogno???
Mi sa che andremo a CASABLANCA!
Decideremo a chi ha la pagliuzza più corta.
ciroteo
2005-06-29 10:19:23 UTC
Permalink
[CUT]
Post by Mariolo
Post by MA
Post by Mariolo
Il codice prodotto non c'è però c'è semplicemente la sigla del
prodotto che è univoca.
Secondo te può bastare?
Hai letto quell'articoletto che sto mettendo online?
www.accessgroup.it/negotium.htm ?
Lo sto tenendo d'occhio...
sicuramente mi servirà quando anch'io dovrò affrontare il magazzino
anche se la mia realtà è più semplice trattandosi di azienda manifatturiera.
Ci sono poche materie prime e pochi prodotti finiti... infatti come ti
dicevo non esistono veri e propri
codici prodotto, ma sigle descrittive.
Penso che comunque si dovrà creare un codice...
Post by MA
Post by Mariolo
Post by MA
non sbandarmelo in questo periodo, anche perchè vorrei mangiare i
confessi rossi prima di quelli bianchi!!!
Il 4 luglio si laurea: che bravo ragazzo, sono orgoglioso di lui!!
ma è vero che ora che ha una posizione avete preventivato un viaggetto in
Spagna per coronare il Vs sogno???
Mi sa che andremo a CASABLANCA!
Decideremo a chi ha la pagliuzza più corta.
o il p.. più lungo ... !
Oscar Manfredini
2005-06-24 11:44:06 UTC
Permalink
Post by Mariolo
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à?
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 :-)
Alessandro Cara
2005-06-24 14:12:28 UTC
Permalink
Oscar Manfredini wrote:
[cut]
Post by Oscar Manfredini
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.
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
Oscar Manfredini
2005-06-24 18:27:03 UTC
Permalink
Post by Alessandro Cara
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.
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
Sandro
2005-06-24 14:37:01 UTC
Permalink
Post by Oscar Manfredini
Le chiavi sono intrinsecamente "parlanti": in varie situazioni la cosa si
apprezza.
E' una soluzione "universale": nessun problema di scalabilità verso altri
motori.
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.
E' un falso problema. Se i campi sono realmente parlanti, prima o poi un
indice (magari non duplicabile) ce lo devi sempre fare.

Semmai sono gli indici delle FK che beneficiano dell'autonumber, rispetto a
portarsi come FK svariati campi ...
Post by Oscar Manfredini
Tra l'altro nel caso si debbano normalizzare tabelle, si dovranno prevedere
indici multicampo "esterni" da legare a quelli della tabella Padre.
Sempre che non torni utile, non si sa mai, avere direttamente nella tabella
relazionata proprio la PK parlante, per risparmiare il join col padre ...
Post by Oscar Manfredini
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.
Anche questa è una cosa detta, consentimelo, con un po di superficialità. Se
due utenti stanno anagrafando il signor Manzoni Alessandro è giusto,
autonumber o no, che il programma di inserimento si faccia carico di testare
se l'anagrafica già esista. E questo test lo devi fare su elementi che non
siano l'ID autonumber, ma qualcosa che sia una PK logica e parlante. Non
credi?
Post by Oscar Manfredini
Analizzati pro e contro, decidete voi :-)
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/
Oscar Manfredini
2005-06-24 18:15:16 UTC
Permalink
"Sandro"
Post by Oscar Manfredini
Post by Oscar Manfredini
Chiavi multicampo allocano, normalmente, molto più spazio su disco
rispetto
Post by Oscar Manfredini
a indici "Long": in pratica significa tempi di manutenzione più lunghi e
DB
Post by Oscar Manfredini
più voluminosi.
E' un falso problema. Se i campi sono realmente parlanti, prima o poi un
indice (magari non duplicabile) ce lo devi sempre fare.
Affermazione ambigua.
Post by Oscar Manfredini
Post by Oscar Manfredini
Tra l'altro nel caso si debbano normalizzare tabelle, si dovranno
prevedere
Post by Oscar Manfredini
indici multicampo "esterni" da legare a quelli della tabella Padre.
Sempre che non torni utile, non si sa mai, avere direttamente nella tabella
relazionata proprio la PK parlante, per risparmiare il join col padre ...
Altra affermazione ambigua: nell'esempio sto parlando di chiavi multicampo
VS autonumbers e non esistono alternative, con se e ma, rispetto a quanto ho
scritto: se crei PK con più campi, dovrai nella tabella "figlio" prevedere
gli stessi campi per la FK.

Punto.
Post by Oscar Manfredini
Post by Oscar Manfredini
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.
Anche questa è una cosa detta, consentimelo, con un po di superficialità.
Quando si legge un'affermazione senza capirla, apparirà superficiale: è
inevitabile.


Se
Post by Oscar Manfredini
due utenti stanno anagrafando il signor Manzoni Alessandro è giusto,
autonumber o no, che il programma di inserimento si faccia carico di testare
se l'anagrafica già esista. E questo test lo devi fare su elementi che non
siano l'ID autonumber, ma qualcosa che sia una PK logica e parlante. Non
credi?
Altra affermazione ambigua.
Post by Oscar Manfredini
Post by Oscar Manfredini
Analizzati pro e contro, decidete voi :-)
Scusami Oscar, ma spunti per analizzare i pro e i contro dal tuo post non ne
emergono.
Non ne emergono perchè non hai capito semplicemente nulla: rileggi meglio il
post e non toccare alcoolici.

Ciao, Oscar
Sandro
2005-06-27 07:42:11 UTC
Permalink
Post by Oscar Manfredini
Post by Sandro
Scusami Oscar, ma spunti per analizzare i pro e i contro dal tuo post
non
Post by Oscar Manfredini
ne
Post by Sandro
emergono.
Non ne emergono perchè non hai capito semplicemente nulla: rileggi meglio il
post e non toccare alcoolici.
Quando ignoranza e presunzione si sposano nasce Oscar Manfredini.

Sono disgustato. Soprattutto dalla tua maleducazione.

Sandro.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Oscar Manfredini
2005-06-27 09:39:15 UTC
Permalink
"Sandro"
Post by Sandro
Quando ignoranza e presunzione si sposano nasce Oscar Manfredini.
Uff ... che palle
Post by Sandro
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
Sandro
2005-06-27 11:36:42 UTC
Permalink
Post by Oscar Manfredini
"Sandro"
Post by Sandro
Quando ignoranza e presunzione si sposano nasce Oscar Manfredini.
Uff ... che palle
Post by Sandro
Sono disgustato. Soprattutto dalla tua maleducazione.
Diciamo che dalla tua risposta parevi un classico Troll con un pò di tempo
libero.
Diciamo che, da persona intelligente quale sei (e ti leggo da tanto tempo)
potresti risparmiarti di dare del troll senza un attimo di riflessione.

Se poi è il confronto, o addirittura la divergenza di vedute che ti
infastidisce, beh forse usenet non è il posto adatto per te.

Quanto al troll, ti prego di non confondere i niubbi con i troll. Essere
niubbi significa *solamente* non essere partecipe in modo frequente alla
vita di un ng, ma non dice nulla ne sulla serietà ne sulla preparazione di
una persona.
Post by Oscar Manfredini
1) non hai capito quanto ho scritto
Oppure
qui non si parla di opinioni, di se e di ma, ma di "matematica".
Oscar, lasciamo perdere. Tutto mi va tranne che scendere nel flame ...
Post by Oscar Manfredini
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).
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)

Sandro.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Oscar Manfredini
2005-06-27 12:10:48 UTC
Permalink
"Sandro" <
Post by Sandro
Diciamo che, da persona intelligente quale sei (e ti leggo da tanto tempo)
potresti risparmiarti di dare del troll senza un attimo di riflessione.
Se poi è il confronto, o addirittura la divergenza di vedute che ti
infastidisce, beh forse usenet non è il posto adatto per te.
Quanto al troll, ti prego di non confondere i niubbi con i troll. Essere
niubbi significa *solamente* non essere partecipe in modo frequente alla
vita di un ng, ma non dice nulla ne sulla serietà ne sulla preparazione di
una persona.
Va bene, ok: parliamone e basta: frequentando poco lo usenet ammetto
d'essere spesso piuttosto brusco.
Brusco ma genuino :-)
Post by Sandro
Post by Sandro
L'utilizzo delle chiavi autoincrement dovrebbe essere circoscritto
*solo*
ai
Post by Sandro
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.
In maniera semplice e pratica si potrebbe riassumere in "le tabelle che
contengono movimentazioni": vedi l'esempio delle testate documento/Righe
Documento.
D'accordo anche con il *solo* (facendo una statistica sui software in
circolazione).
Post by Sandro
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.
Attenzione: e qui ritorno a citare il post che ha dato origine al diverbio.

"Diciamo che se una tabella già contiene un campo univoco è logico
utilizzare quello come chiave primaria"

Da questo si evince che NON credo affatto si debbano utilizzare autonumbers
con archivi anagrafici.

Poi ho fatto un esempio, sempre relativo ad archivi anagrafici, che
effettivamente pone il fianco ad obiezioni (CodiceDitta + CodiceArticolo) e
tu hai esagerato attribuendomi cose che non ho scritto.
Anche se troppo frettolosamente ti ho dato del Troll, francamente hai
esagerato in quella risposta.
Post by Sandro
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
SELECT codice_articolo,sum(qty_piu_meno) as movimentato FROM Movimenti
WHERE cod_fornitore='TIZIO'
GROUP BY codice_articolo
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.
Beh, e nel contempo credo bene di sapere che differenza faccia un Join con
qualche milione di records visto che lavoro a tutt'oggi nella pubblica
amministrazione :-)

Ma come dicevo prima m'hai fatto dire cose diverse da quelle che ho scritto:
l'esempio che mi fai rientra nell'ambito dell'affermazione d'esordio di quel
post:

"Diciamo che se una tabella già contiene un campo univoco è logico
utilizzare quello come chiave primaria"

Tuttavia se fosse necessario nell'ambito dell'anagrafica articoli inserire
un codice Ditta le cose diverrebbero più ambigue.
Meglio introdurre un autonumber o creare una chiave bicampo per identificare
l'articolo?
Chiave bicampo che dovrai "trascinare" anche nelle righe Documento, con
incremento significativo di dimensione dell'indice e maggior carico di
lavoro del motore per mantenere l'indice.

Inoltre alla tabella Anagrafica Articolo potrebbero essere relazionate
decine di altre tabelle (Lotti, Struttura DIBA, collegamenti hipertestuali,
Sconti promozionali, Listini articolo, Referenze Fornitore, e tanto altro).
Questo significherebbe dover creare FK bicampo in tutte le tabelle:
indubbiamente un bello spreco di spazio su disco rispetto a un autonumber!

Questa che descrivo è una situazione posta nella "linea d'ombra", esempio
che potevo risparmiarmi ma che tu hai usato come macigno: gratuitamente.
Post by Sandro
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.
Nell'esempio che fai te è chiaro che non si risparmia: ma è ben diverso
dalla situazione descritta più sopra, quella origini del "flame".
Post by Sandro
;-) (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
Sandro
2005-06-27 13:43:22 UTC
Permalink
"Diciamo che se una tabella già contiene un campo univoco è logico
utilizzare quello come chiave primaria"
Tuttavia se fosse necessario nell'ambito dell'anagrafica articoli inserire
un codice Ditta le cose diverrebbero più ambigue.
Meglio introdurre un autonumber o creare una chiave bicampo per identificare
l'articolo?
Chiave bicampo che dovrai "trascinare" anche nelle righe Documento, con
incremento significativo di dimensione dell'indice e maggior carico di
lavoro del motore per mantenere l'indice.
E' questo che non riesco a condividere, Oscar. Di quale incremento parli?
Per come vedo io la questione, una chiave (fornitore,codice) dovrei averla
comunque. In cosa risparmio con un autonumber?
Inoltre alla tabella Anagrafica Articolo potrebbero essere relazionate
decine di altre tabelle (Lotti, Struttura DIBA, collegamenti
hipertestuali,
Sconti promozionali, Listini articolo, Referenze Fornitore, e tanto altro).
indubbiamente un bello spreco di spazio su disco rispetto a un autonumber!
Ah forse ho capito! Il risparmio è sulle FK? Vero?
Questa che descrivo è una situazione posta nella "linea d'ombra", esempio
che potevo risparmiarmi ma che tu hai usato come macigno: gratuitamente.
Post by Sandro
;-) (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.
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.

Sandro.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Oscar Manfredini
2005-06-27 14:42:32 UTC
Permalink
"Sandro"
Post by Oscar Manfredini
Post by Oscar Manfredini
Tuttavia se fosse necessario nell'ambito dell'anagrafica articoli inserire
un codice Ditta le cose diverrebbero più ambigue.
Meglio introdurre un autonumber o creare una chiave bicampo per
identificare
Post by Oscar Manfredini
l'articolo?
Chiave bicampo che dovrai "trascinare" anche nelle righe Documento, con
incremento significativo di dimensione dell'indice e maggior carico di
lavoro del motore per mantenere l'indice.
E' questo che non riesco a condividere, Oscar. Di quale incremento parli?
Per come vedo io la questione, una chiave (fornitore,codice) dovrei averla
comunque. In cosa risparmio con un autonumber?
E lo chiedi?
Risparmi in maniera determinante sulle FK! :-)

Non dimentichiamo che un'anagrafica articoli, o di altro genere, contiene un
volume limitato di records: spesso poche centinaia (vabbè, ferramente ed
elettricisti fanno eccezione).
Gli archivi correlati indirizzano spesso un volume di dati 3/4 volte
superiore.
Gli archivi che contengono movimentazioni ... beh, praticamente infiniti col
passar degli anni.

Quindi in una situazione del genere il risparmio di spazio su disco (e
dimensioni indici) è francamente notevole.
Post by Oscar Manfredini
Post by Oscar Manfredini
Inoltre alla tabella Anagrafica Articolo potrebbero essere relazionate
decine di altre tabelle (Lotti, Struttura DIBA, collegamenti
hipertestuali,
Post by Oscar Manfredini
Sconti promozionali, Listini articolo, Referenze Fornitore, e tanto
altro).
Post by Oscar Manfredini
indubbiamente un bello spreco di spazio su disco rispetto a un autonumber!
Ah forse ho capito! Il risparmio è sulle FK? Vero?
Beh: lo vedi che non hai letto bene il post della discordia?
Post by Oscar Manfredini
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.
Mhmmm: però non mi pare che ti sia sembrato così ovvio il discorso sugli
indici esterni.
In pratica mi pare che tu mi abbia attaccato valutando esclusivamente il
discorso PK e non FK: o sbaglio?
Post by Oscar Manfredini
Fra l'altro, anche altri meno
niubbi di me ti hanno fatto notare le medesime cose.
Alessandro Cara?
Beh: lui ha fatto precisazioni aggiuntive (anche relative agli indici
secondari sui campi Join) non ha smentito quanto ho scritto.
Ne d'altra parte ho sostenuto tesi azzardate, mi permetto d'aggiungere!
Post by Oscar Manfredini
la presunta semplicità del sw lato client in caso di FK numeriche. Come può
il client essere più semplice con gli autonumber?
Come può essere più semplice rispetto all'utilizzo di chiavi multicampo?
Beh, insomma: la risposta in sè appare scontata...
Post by Oscar Manfredini
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 ... ;-)
Accidenti: addirittura da evitare come la peste!
Non ho lavorato con myODBC ma con SQL Server e campi identity sì: eccome
(quantomeno in rapporto alle problematiche di normalizzazione che ho
esposto, non certo con archivi anagrafici già identificati dal codice).

E in tutta onestà con quella configurazione i campi identity non danno alcun
problema di gestione, ne potrebbero darne: soluzione semplice e solida.

D'altra parte dubito che le cose cambino con MySQL.
Post by Oscar Manfredini
A questo aggiungici l'aumento di complessità delle selezioni e poi cerca di
sostenere ancora la tesi della semplicità.
Aumento di complessità delle selezioni??
Oddio: forse non riesco più a seguirti ... cosa c'è di più semplice di un

Select From NomeTabella Where IDTalDeiTali= <XYZ>?
Post by Oscar Manfredini
Oscar, malintesi a parte è stato un immenso piacere confrontarsi.
Ma senti un pò Sandro .... sarai mica SandroBi con nick name modificato
vero?

Ciao, Oscar
Alessandro Cara
2005-06-28 17:42:06 UTC
Permalink
Oscar Manfredini wrote:
[cut]
Post by Oscar Manfredini
Alessandro Cara?
Beh: lui ha fatto precisazioni aggiuntive (anche relative agli indici
secondari sui campi Join) non ha smentito quanto ho scritto.
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
2005-06-28 21:35:09 UTC
Permalink
"Alessandro Cara" <
Post by Alessandro Cara
Post by Oscar Manfredini
Alessandro Cara?
Beh: lui ha fatto precisazioni aggiuntive (anche relative agli indici
secondari sui campi Join) non ha smentito quanto ho scritto.
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)
Ma non per chi ha lavorato in Cobol (o RPG)...

, ero abituato a trattare dati
Post by Alessandro Cara
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.
Vero, ma per ogni DB (io in particolar modo mi riferisco a MS SQL Server) è
abbastanza semplice reperire le informazioni per fare i due calcoli
necessari alla previsione.
E in questi casi non ci sono molte sorprese: conta la matematica.
Post by Alessandro Cara
Su questo, quando lavoravo sui file VSAM-KSDS, (hai citato il
Cobol e la P.A. quindi puo' darsi che tu sappia cosa sono)
Come no...
Post by Alessandro Cara
, 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
Sì ma questo discorso è valido solo nell'ipotesi che si abusi dei Counters
(vedi esempio fatto da Sandro): ci sono mille modi di boicottare
l'efficienza di un DB con o senza AutoNumbers ... vuoi per inesperienza o
incapacità.
Altro discorso.
Post by Alessandro Cara
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
Sandro Binetti
2005-06-29 09:48:32 UTC
Permalink
Post by Oscar Manfredini
Sì ma questo discorso è valido solo nell'ipotesi che si abusi dei Counters
(vedi esempio fatto da Sandro): ci sono mille modi di boicottare
l'efficienza di un DB con o senza AutoNumbers ... vuoi per inesperienza o
incapacità.
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.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Oscar Manfredini
2005-06-29 10:59:52 UTC
Permalink
"Sandro Binetti" <
Post by Sandro Binetti
Post by Oscar Manfredini
Sì ma questo discorso è valido solo nell'ipotesi che si abusi dei Counters
(vedi esempio fatto da Sandro): ci sono mille modi di boicottare
l'efficienza di un DB con o senza AutoNumbers ... vuoi per inesperienza o
incapacità.
Altro discorso.
Quello che non condivido di questo approccio è che si parta
dall'ottimizzazione piuttosto che dallo scenario.
Un momento: io ho solo descritto la realtà per quella che è ... non ho
proposto approcci "filosofici" di alcun tipo!

Quando si disegna
Post by Sandro Binetti
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.
Il discorso che stai facendo non aggiunge o toglie nulla a quanto ho
scritto.
E non è (ne può essere) in contraddizione con quanto ho scritto.

Nel Thread sono stati fatti esempi assai pratici di casistiche in cui:

1) E' poco razionale usare un "counter"
2) E' razionale, anzi consigliabile, usare un "counter"
3) Situazioni ambigue, diciamo al 50%

Questa è la realtà delle cose: c'è poco da aggiungere o togliere.
Prendo atto del fatto che qualcuno sposi esclusivamente la causa numero 1)
... ma nulla di più: è un approccio che si rivelerà oneroso e
insoddisfacente in varie casistiche.

Mi pare inutile ripetere concetti espressi con dovizia di dettagli nei
precedenti post(s).
Post by Sandro Binetti
Insomma, ne faccio una questione di metodo. Perchè è il metodo che, imho,
fa> la differenza fra il professionista (informatico) serio e
l'improvvisato.
E
Post by Sandro Binetti
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.
Sarà senz'altro così, ma è un discorso che non riguarda direttamente
l'oggetto di questo Th.

Ciao, Oscar
Cristiano
2005-06-25 09:13:32 UTC
Permalink
"Oscar Manfredini"
Post by Oscar Manfredini
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.
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
Sandro
2005-06-27 13:44:35 UTC
Permalink
E non prendertela per i Troll: li trovi ovunque ormai! ;-)
Eccone un altro ...

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Cristiano
2005-06-27 16:55:29 UTC
Permalink
"Sandro" <
Post by Sandro
E non prendertela per i Troll: li trovi ovunque ormai! ;-)
Eccone un altro ...
Spiacente, ma la sensazione era quella.
Sandro
2005-06-28 09:10:27 UTC
Permalink
Post by Oscar Manfredini
"Sandro" <
Post by Sandro
E non prendertela per i Troll: li trovi ovunque ormai! ;-)
Eccone un altro ...
Spiacente, ma la sensazione era quella.
Se basta una semplice sensazione per classificare una persona vuol dire che
siamo davvero messi male.

Sandro.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Cristiano
2005-06-28 14:56:55 UTC
Permalink
"Sandro" <
Post by Sandro
Post by Cristiano
Spiacente, ma la sensazione era quella.
Se basta una semplice sensazione per classificare una persona vuol dire che
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
Sandro
2005-06-28 15:51:17 UTC
Permalink
Post by Cristiano
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.
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.

Sandro.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
Cristiano
2005-06-28 15:59:21 UTC
Permalink
"Sandro"
Post by Sandro
Post by Cristiano
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.
Sarai anche un aficionado,
Non lo sono per nulla
Post by Sandro
ma non ho visto alcun tuo reply al mio post, ma
solo quello di Manfredini.
Mi pare sia stato già detto tutto.
Post by Sandro
Se hai qualcosa da obiettare in merito a quanto ho scritto, fallo in modo
canonico, quota, rispondi, obietta, rivendica.
Qualcosa da obiettare?
Per esempio: che problemi di biblica portata avresti avuto con i Counters in
mySQL?
Post by Sandro
Io potrò anche aver detto cazzate, ma non ho dato del deficiente a
Manfredini rispondendo al mex di un altro.
Mica t'ho dato del deficiente: semplicemente anch'io sulle prime pensavo
fossi un Troll.

Cristiano
Oscar Manfredini
2005-06-28 16:53:34 UTC
Permalink
"Sandro" <
Post by Sandro
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.
Ei ragazzi: adesso non cominciate vuoi due eh? ;-D

Piuttosto Sandro: mi sei debitore ancora di una risposta...

Ciao, Oscar
Sandro
2005-06-28 19:43:16 UTC
Permalink
Post by Oscar Manfredini
"Sandro" <
Post by Sandro
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.
Ei ragazzi: adesso non cominciate vuoi due eh? ;-D
Piuttosto Sandro: mi sei debitore ancora di una risposta...
Ciao, Oscar
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.
Oscar Manfredini
2005-06-28 21:38:30 UTC
Permalink
"Sandro" <>
Post by Sandro
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.
Beh, è il minimo che possa capitare considerando la *scarsa* diffusione del
vostro nome!
Al posto tuo indicherei il cognome oltre al nome :-)
Sandro
2005-06-28 21:47:42 UTC
Permalink
[cut]
Post by Oscar Manfredini
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 ?
Oscar Manfredini
2005-06-28 21:51:08 UTC
Permalink
"Sandro"
Post by Sandro
Ma come mai quella domanda allora ? Vi conoscete per esservi incontrati in
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
Sandro Binetti
2005-06-29 07:50:31 UTC
Permalink
Post by Sandro
Sandro se vedi questo post dimmi come la pensi sul fatto di identificarci
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.

--------------------------------
Inviato via http://arianna.libero.it/usenet/
MA
2005-06-29 07:51:56 UTC
Permalink
Il 28 Giu 2005, 21:43, "Sandro"
Post by Sandro
Sandro se vedi questo post dimmi come la pensi sul fatto di
identificarci 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.
Considera che il tuo clone è stato fornato a beccare te.
In precedenza un suo omologo è cascato molto ma molto peggio!!!
--------------------------------
Inviato via http://arianna.libero.it/usenet/
--
_ _
Ciao
MAssimiliano Amendola www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info: www.donkarl.com/it
MA
2005-06-29 07:53:49 UTC
Permalink
Post by MA
Il 28 Giu 2005, 21:43, "Sandro"
Post by Sandro
Sandro se vedi questo post dimmi come la pensi sul fatto di
identificarci 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.
Considera che il tuo clone è stato fornato
ops fortunato!!!
devo cambiare la tastiera assolutamente!!!
Post by MA
a beccare te.
In precedenza un suo omologo è cascato molto ma molto peggio!!!
--------------------------------
Inviato via http://arianna.libero.it/usenet/
--
_ _
Ciao
MAssimiliano Amendola www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info: www.donkarl.com/it
Mariolo
2005-06-29 08:48:06 UTC
Permalink
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
Sandro Peruz
2005-06-29 21:49:04 UTC
Permalink
Il 28 Giu 2005, 21:43, "Sandro"
Post by Sandro
Sandro se vedi questo post dimmi come la pensi sul fatto di
identificarci
Post by Sandro
meglio.
Ok.
Ciao Sandro,
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.
da oggi mi sa che mi adeguerò anch'io.
Mi scuso per aver generato, mio malgrado, questa confusione ;-)
fa niente, anche io c'ho messo del mio. Era un po' che volevo intervenire
per chiedertelo. ( il fatto della modifica del nick name ...meglio
spedificarlo, altrimenti qualcuno fraintende ). Problema risolto.
Ciao, Sandro.
Ciao, Sandro.

Sandro Binetti
2005-06-29 07:52:39 UTC
Permalink
Post by Oscar Manfredini
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/
Oscar Manfredini
2005-06-29 10:48:47 UTC
Permalink
"Sandro Binetti" <
Post by Sandro Binetti
Post by Oscar Manfredini
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?
Mi riferisco al post del 27 Jun 2005 16:42:33
Quello che termina con: "ma sarai mica SandroBi vero"? :-)

Ciao, Oscar
Continua a leggere su narkive:
Loading...