Newsgroup: it.comp.appl.access
Titolo: Un vostro parere sulle chiavi di tabella

Sono abbastanza nuovo del NG, ma mi ha colpito una cosa, di cui vorrei un
Vs. parere. Ho notato che la maggioranza degli utenti, se non tutti, fanno
uso esclusivamente di campi contatore per le chiavi delle tabelle. Questa è
indubbiamente una comodità per il programmatore, ma non lo è per l'utente
finale, in quanto un numero non ha appigli mnemonici e quindi il codice
articolo o il codice cliente non può essere ricordato, nè fornisce qualche
tipo di informazione sull'articolo. Se ad esempio si ha da gestire un grosso
magazzino l'ID degli articoli non è quasi mai un campo numerico ma
alfanumerico, in quanto il codice include informazioni utili (se non
propriamente menemoniche) anche per la categoria dell'articoli, il
fornitore, lo scaffale, ecc. Inoltre spesso è utile usare i codici stessi
dei fornitori per non dover raddoppiare il campo e avere già un codice utile
per il riordino, ecc. ecc.
Allora come mai questo uso massiccio del campo contatore come chiave
primaria? Non andrebbe altrettanto bene un campo testo di una decina di
caratteri impostato come chiave primaria?
Saluti a tutti
Arturo

 ha scritto nel messaggio
news:zHy97.5225$y_3.4...@news.infostrada.it...

Ciao Arturo,
nessuno ti vieta di utilizzare un campo testo come chiave primaria e in
alcune, poche, circostanze lo faccio anch'io.
La differenza la fa Access, poiché gli riesce + veloce tenere un indice su
un valore numerico Long rispetto ad un testo, e, nelle tabelle relazionate
con questo campo, occupi comunque meno spazio e hai una minore ridondanza di
valori.
Inoltre, il fatto di utilizzare un campo contatore come chiave primaria non
esclude assolutamente l'uso di un campo contenente un testo x facilitare
l'utente nelle sue scelte.
Tutto questo oltre alla certezza che, salvo errori dovute a schede di rete
marce (vero Luciana?), non avrai la duplicazione dell'indice.
--
Silvio
il sito comune di it.comp.appl.access:
http://www.sitocomune.com

 ha scritto nel messaggio
news:zHy97.5225$y_3.4...@news.infostrada.it...


 G.F.
Saluti ricambiati
Arturo

 fornitore, lo scaffale, ecc.
Le chiavi contatore (come già ti ha postato Silvio Berruti) sono un
eccellente strumento di normalizzazione tabelle: velocissime, univoche in
multiutenza senza scrivere codice, semplici da usare.
MA, non devi usarle a mò di codice cliente o articolo! :-)
Sono due concetti diversi da non confondere
Ovviamente a volte può far comodo ricorrere a una chiave primaria
alfabetica, ma a parer mio è svantaggioso in una "catena" di tabelle
collegate: sei costretto a ricorrere a chiavi alfamumeriche multicampo ...
lentissime.
Lascia perdere invece i suggerimenti d'incremento a codice di campi numerici
che trovi sul sito comune: in multiutenza rischi la vita :-)
Ciao, Simone


--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 Per la mia esperienza no; o almeno quasi mai.
Strano perchè la maggior parte dei gestionali in commercio usa solo codici
alfanumerici compreso anche l'ultimo della ESA, appena uscito e tutto in
VBA.
Saluti
Arturo


Ma siamo così sicuri che un utente riesca a ricordare a memoria ovvero a
districarsi tra circa 10.000 o più codici anche se questi sono di tipo
alfanumerico?
Ciao,
Salvatore

 Salvatore
Beh, dunque si calcola che nel cervello ci siano 10E15 sinapsi, ciascuna
capace di memorizzare un byte, direi che la cosa sia fattibile ... :-)
Dipende da come si impostano i codici, ad esempio per i libri si compongono
con le prime 3 lettere del cognome dell'autore, piů le ultime 4 cifre cel
codice ISBN, in tal modo se devi inserire la vendita di un libro di Bozzani
Arturo, basta che digiti BOZ e ti esce una lista ristretta di codici tra cui
scegliere. Se vendessi auto metterei la marca ad esempio FIA (per Fiat), REN
(per Renault) ecc. Per i clienti si puň fare la stessa cosa 3 lettere del
cognome + 3 del nome + eventualmente un altro carattere (un numero o la
sigla della provincia) in caso di omonimia. Anche in questo caso digitando 3
lettere hai una lista ristretta. Ecc. i sistemi possono essere tanti.
Ciao
Arturo

 questa è una legge fondamentale nella programmazione e non solo.
Scusa Arturo, ti stai urtando con uno dei migliori esponenti del ng. per dei
cavilli.
Non parlarmi di Esatto che è una merda assoluta: se i tuoi modelli di
software "professionali" sono questi (basati su analisi Cobol vecchie di 20
anni) stai fresco.
Le procedure di nuova concezione usano spesso campi numerici e autonumber
per la normalizzazione, chi non li usa è per due ragioni:
1) analisi vetusta e poca voglia di riconcepirla
2) l'ambizione di avere un BE universale (jet e SQl server supportano gli
autonumber, altri DB no).
Le chiavi alfabetiche multicampo sono *belle* da leggere, ma hanno
prestazioni pessime e occupano un mare di spazio su disco.
Ciao, Simone

 Ciao, Simone
Ciao, Arturo

 ha scritto nel messaggio
news:5AF97.1289$_07....@news.infostrada.it...

Sai una cosa? Mi hai convinto.
Nel prossimo DB che progetto userň chiavi alfanumeriche. Normalmente uso il
contatore che mi consente, tra l'altro, di non far inserire all'utente i
valori in un campo fondamentale.
Resta il fatto che poi il codice se lo deve inventare l'utilizzatore, il
quale, magari per pigrizia o per ignoranza (capita, oh se capita...) usa di
nuovo i numeri. In ogni caso, un buon operatore dovrebbe trovarsi piů a suo
agio con i codici alfanumerici che con queli numerici.
Sai che comunque mi č capitato di incontrare operatori che si ricordano a
memoria i codici numerici di centinaia di persone o comunque di articoli,
oggetti ecc.
Ciao,
Salvatore

Ero tentato di risponderti punto per punto, ma visto che il dialogo era
diventato molto polemico ritengo sia una cosa intelligente abbandonare
questo thread, se non altro per rispetto degli altri partecipanti, che
sicuramente trarranno da soli le valutazioni delle argomentazioni esposte.
Comunque certe strutture di chiave le ho abbandonate quando tanti anni fa ho
abbandonato il Cobol e ho cercato di capire come era meglio progettare
l'architettura di un database relazionale; a quanto pare ho regredito
anziché progredire: probabilmente è colpa dell'età.
Se poi ti va di sfatare la leggenda metropolitana dimmelo: oltre ad alcuni
frequentatori di questo NG ti posso presentare qualche buon
analista/programmatore.


italiano in alternativa.
Premessa: Roberto non è solo bravissimo ma anche molto disponibile con tutti, non rilevo contenuti
offensivi nel suo post e secondo me sei stato gratuitamente polemico nei suoi confronti.
Mandami un'e-mail e ti indico un sito da cui scaricare una valida alternativa ad Esatto.
Ultimamente ne stiamo sostituendo diversi in aziende che, scioccate, vogliono avere finalmente fra
le mani qualcosa che assomigli a un programma :-)
Ci vado pesante? No, pura verità.
La cosa paradossale è che i predecessori DOS di Esatto e similari erano rozzi graficamente, ma per
lo più decisamente buoni ... evidentemente dopo lustri di "lima e martello" i maghi del Cobol
avevano raggiunto la quadratura del cerchio.
Ci sono pro e contro nell'utilizzo di chiavi autonumber o alfanumeriche multicampo per la
normalizzazione di tabelle relazionate:
Autonumber:
PRO:          velocissimi, molto compatti, univoci in multiutenza senza scrivere alcunchè
CONTRO:    supportati da M$ JET e M$ Sql-Server ma non da tutti i motori sul mercato, non sono
*parlanti* e quindi è più ostico capire DB scritti da altri, per forzare un valore del contatore si
deve intervenire a codice.
Chiavi multicampo:
PRO:          sono facili da leggere (parlanti appunto), si possono assegnare manualmente i valori
delle chiavi, sono universali e non legate a un particolare DB.
CONTRO:    lentissime (in proporzione quasi geometrica rispetto ai Long), pesanti, richiedono
interventi di programmazione per la gestione di conflitti in multiutenza.
A parer mio chi usa DB M$$ e non ambisce a produrre software universali (quelli che funzionano MALE
con tutti i motori sulla faccia della terra) è meglio che ricorra ai buon vecchi autonumber per le
normalizzazioni più impegnative.
Questo non esclude l'utilizzo in casi particolari di chiavi alfabetiche: per esempio in tabelline
accessorie CODICE/DESCRIZIONE.
La pessima fama di M$ JET in fatto di prestazioni è legata proprio alle scelte infami di
normalizzazione che i produttori dei vari Diamante, Company, Swing, Business etc. hanno operato.
Hanno fatto una scelta politica: riciclare pari, pari l'analisi delle vecchie procedure DOS (che
giravano però con una logica Terminal/server) penalizzando in maniera inaccettabile prestazioni e
affidabilità.
Ciao, warp

 è solo una questione di principio, cioè l'ottica del programmatore?
Vorrei vederli questi DB e  valutare la complessità delle query che hai
scritto e le problematiche che risolvono.
Le mie personali esperienze vanno in direzione esattamente opposta.
Non ti dico poi i prodotti commerciali su base Jet che circolano (uno su
tutti: BUSINESS) ... tempo panino per qualunque elaborazione.
Ciao, Simone


Ciao
Arturo

 tutti: BUSINESS) ... tempo panino per qualunque elaborazione.
Dipende anche dalle CPU e dalla RAM che hai sotto ...
Ciao
Arturo

 analista/programmatore.
Come ho già scritto in un altro post, sto cercando un programmatore in ASP
per il commercio elettronico, si tratta di un lavoro di medie-grandi
dimensioni.
Ciao
Arturo


Beh, hai capito male.
Non sono né programmatore, né analista: come molti frequentatori del NG
sanno, sono un dirigente di una grande azienda editoriale nella quale sono
un utente e non un attore dell'informatica.
Per il resto continuo a non condividere quasi nessuno dei tuoi punti di
vista: questo te lo dico come dirigente.


 Dipende anche dalle CPU e dalla RAM che hai sotto ...
Mah, ti assicuro che Diamante e Business sono lentissimi anche con
configurazioni hardware performanti.
Ciao, Simone

 Sono curioso di natura :-)
Lo trovi sul sito dell'Esa:
http://www.esasoftware.com
Avrà varie versioni: e-uno, e-due, ecc.
Saluti
Arturo

 anziché progredire: probabilmente è colpa dell'età.
sembrava che tu facessi il programmatore, invece non sei né un programmatore
né un analista ma un semplice utente... che si diletta  a progettare
database relazionali al di fuori del lavoro. Bastava dirlo subito!
Di nuovo
Arturo

si stanca e rallenta è la persona, non la macchina.
L'uso di autonumber non influenza in alcun modo la concezione dell'interfaccia utente: lenta,
veloce, bella o brutta che sia dipende da tutt'altro.
Mah, continuo a pensare che ci siano equivoci sull'uso di questi campi...
Ciao, warp