Newsgroup: it.comp.lang.visual-basic
Titolo: Chiavi Contatore Vs Alfanumeriche

Ciao a tutti,
devo iniziare un nuovo progetto che avr� dei master/detail in cascata.
TabCliente
	Tab1 #nrecord
		Tab2 #nrecord
			Tab3 #nrecord
ecc.
Avevo gi� aperto tempo fa un topic sul NG dei DB, ma volevo riverificare un
attimo la cosa.
Mi trovo a dover scegliere se gestire le chiavi delle tabelle come
auto-increment, oppure come alfanumerici.
Nel primo caso la gestione � pi� semplice, ma il "numero" non parla per la
ricerca da parte dell'utente( es. PAGAMENTO ID=1)
Nel secondo caso (es. PAGAMENTO COD='RB3060') il codice fa capire subito di
che si parla, ma dovrei gestire bene le integrit� referenziali (o bloccare
la modifica dei codici), inoltre se uno volesse usare i codici "numerici"
mi trovo in difficolt� a *proporre* un codice valido es. "000001" o "1" ma
nel secondo caso perdo gli ordinamenti, e NON VOGLIO memorizzare i codici
in un modo e farli vedere in un altro.
Fino ad ora ho adottato spesso la prima soluzione, con eventualmente un
campo "CODICE" nelle tabelle per facilitare le ricerche. Ma anche cos� fare
le ricerche su doppio campo � "noioso": 
Select ... WHERE Cliente.ID='1' OR Cliente.Codice='1'
Come vi comportate voi?
Tnx

 auto-increment, oppure come alfanumerici.
la prima che hai detto.
-- 
Salutoni
Sergio
C'� il giorno in cui nasci e quello in cui scegli di vivere
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Come vi comportate voi?
Da quando abbiamo iniziato a lavorare sui database di Dynamics AX, 
abbiamo deciso di adeguarci a ciï¿œ che sembra essere diventato lo 
standard MS.
Ogni record di ogni tabella contiene una valanga di informazioni di 
debug, come un autoincrementante (che cosï¿œ ci dï¿œ l'ordine di 
inserimento), utente e date di creazione, utente e data di ultima 
modifica, e altre cosine belle.
I codici sono tutti NVarChar(20) (il 20 non ï¿œ fisso, esistono 
eccezioni, ma diciamo che il 90% delle tabelle ï¿œ cosï¿œ).
Quindi noi abbiamo deciso che gli id delle tabelle siano tutti 
NVarChar(20). Nei casi in cui non ci serve un codice 'umano' (ad 
esempio in una tabella di relazione, in cui di fatto l'id della 
relazione viene generato dal sw e non dall'utente), il campo codice 
viene popolato come colonna calcolata As Cast(autoincrmeentale as 
nvarchar(20)) Persisted Unique.
E' chiaro che in questo caso perdo l'order by. Ma non ï¿œ vero, perchï¿œ ho 
sempre l'autoincrementale che ï¿œ coerente col codice alfanumerico. 
Quindi se devo ordinare, uso il numerico, se devo fare delle chiavi 
esterne uso sempre l'alfanumerico (cosï¿œ uso sempre quel tipo a 
prescindere che sia un codice generato automaticamente o inserito 
dall'utente).
Aggiungo che siccome nessun nostro software va mai a eseguire Insert, 
Update, Delete o Select su tabelle, ma i client possono SOLO invocare 
delle stored procedure che eseguono quanto serve, posso anche 
permettermi di eseguire insert in una tabella specificando un codice a 
mano o lasciando che venga generato dalla SP qualora il codice passato 
come parametro sia vuoto o Null.
Un caso tipico ï¿œ quello dei codici articolo e dei codici dei campioni. 
Se voglio inserire l'articolo "Biro Blu" lo digito, se devo inserire un 
articolo che in realtï¿œ ï¿œ un campione e non me ne frega niente del 
codice che gli viene assegnato, la SP fa un cast dell'autoincrementale 
a nvarchar, verifica che non esista giï¿œ e nel caso c'ï¿œ un algoritmo di 
generazione di una nuova chiave semi-random, e quindi restituisce il 
codice generato al client.
Alberto


Io faccio cos�: il campo counter ("ID") � Primary Key, usato nelle relazioni 
con tabelle secondarie, mentre il campo alfanumerico ("Codice") � solo una 
unique key.
Ah, mai usare un campo "parlante" come PK o FK (foreign key), porta solo 
rogne.
Per le ricerche, solitamente l'utente usa il campo "Codice", in alternativa 
propongo anche una ricerca in base ad "ID", ma mai in OR, o uno o l'altro.
Per i record nuovi della tabella Master, il campo "Codice" o � blank (ma 
deve poi essere necessariamente valorizzato dall'utente) oppure viene 
proposto un valore "progressivo" calcolato sulla base dei record 
"precedenti", dipende dallo scopo della tabella...
Bye
Raf 

On 29 Ott, 10:35, "Andrea [Work]"
<andrea.isworkDELET...@gmail.invalid> wrote:
zac
Io sto maledicendo le cattive abitudini prese con access ed il suo
stramaledetto campo contatore.
Comodo solo se rimarrai sempre e soltanto con access!
Altrove c'è roba molto più versatile (adesso sto cominciando a
spippolare con postgresql....e lì ci sono le sequenze) ma anche più
tosta da capire!
La natura del codice è la causa del suo tipo!
Mi spiego ...se è solo una faccenda interna...per eliminare
velocemente un record....allora un numero!(è quello che prende meno
posto in memoria) che sia autogenerato o un timestamp o un guid o
quello che vuoi dipende dal motore db!
viceversa
Se è una faccenda in mano all'uTonto...allora lui in genere preferisce
l'alfanumerico es "BulloniAd78932" "RateiDiversi01" "Scaffale12" etc
etc...tanto poi ti chiederà di metterglieli in un combobox o in una
"finestrina" (sic) di ricerca!
E non vorrà nemmeno una generazione automatica: "ScaffaleA112" lo
vuole scrivere lui!
Hai presente il commesso che sbuffa perchè il trancio di prosciutto
cotto non passa alla cassa e lo deve scrivere a mano?(...che brutti
ricordi!Per un periodo della mia vita mi son trovato da quella parte
della barricata!!! brrrrrr!)

 della barricata!!! brrrrrr!)
:)
Comunque vista la tipologia di software, quasi tutte le tabelle possono
essere AutoIncrement. La tabella clienti la eredito da un DB gi� presente
ed � gi� gestita per conto suo. Quasi tutte le tabelle correlate possono
esserlo solo per ID. Tanto l'utente mai si ricorder� di quei codici, ma
cliccando sul cliente, vedr� la situazione tanto si parla penso di un 10/20
righe detail massimo per ogni master, quindi grigliabili senza prolemi.

 "precedenti", dipende dallo scopo della tabella...
Quello si avrebbe senso. Potrebbe essere un progressivo relativo al master.
Cio� una "Select MAX() +1 WHERE MasterID=xxx". Magari la Paddo con gli 0
(0001, 0002 per gli order).
E' sicuramente comodo cos�, il cliente se vuole si cambia il codice di
ricerca quando vuole. Forzando come UNIQUE INDEX poi ci si pu� permettere
di stampare quello nelle varie stampe.
Di contro nelle stampe varie devi joinare sempre la tabella per avere il
codice. Nel mio caso  non sar� un problema partendo da zero.

 codice generato al client.
Negli articoli ho i campi IDArticolo, CodArticolo, DescrizioneArticolo.
Il primo � autoincrement e la chiave globale ovunque, � anche un campo di
ricerca/richiamo.
Il campo CodArticolo non � obbligatorio metterlo, ma il programma avverte
se non metti niente, e ti avverte sui duplicati, anche se te li fa fare.
Anche questo � nelle ricerche e stampe.
Voglio proprio evitare questo discorso di avere due campi che un cliente ne
usa uno, un cliente un'altro (ho aziende grossotte in cui i commerciali
usano i numeri, e in magazzino usano i codici alfanumerici). Poi nella
stampa ci metti il codice e qualcuno ci vuole l'ID, allora rendi
parametrizzabile la stampe ecc. Insomma si perde la strada per tornare a
casa :)

 la prima che hai detto.
C'� qualche motivazione rispetto alla "comodit�"?

 il codice. Nel mio caso  non sar� un problema partendo da zero.
Esatto.
Bye
Raf 

On 29 Ott, 16:04, "Andrea [Work]"
<andrea.isworkDELET...@gmail.invalid> wrote:
zac
Rimane comunque il problema di fondo......
tu fai ancora cercare per codice il tuo utonto
io nel 2009....quasi 2010....la considero una follia!
nota bene non sono talebano:
ricordarsi il codice di una causale...è diverso da ricordarsi il
codice di un articolo di magazzino...o di un cliente....se serve si
fà!
MA
.....
Un piccola form di ricerca...nei casi con pochi record un combo!
Oramai il codice lo metto solo per aiutare me
programmatore...all'utonto non lo faccio più vedere....faccio vedere
direttamente la descrizione o la ragione sociale!
Sono impostazioni....visioni "politiche"...e come tali mutevoli da
programmatore a programmatore!

 C'� qualche motivazione rispetto alla "comodit�"?
No, non particolarmente. personalmente uso la chiave primaria di una
tabella solo come riferimento per i record associati in altre tabelle, non
viene mai mostrata all'utilizzatore finale, e un dato numerico � pi�
compatto e consente una maggiore velocit�.
l'handicap di questo approccio � che rende difficoltoso il "merge" di dati
provenienti da diversi database per la possibilit� (direi la certezza) di
duplicazioni di chiavi.


Hai presente il commesso che sbuffa perch� il trancio di prosciutto
cotto non passa alla cassa e lo deve scrivere a mano?(...che brutti
ricordi!Per un periodo della mia vita mi son trovato da quella parte
della barricata!!! brrrrrr!)
oddio, nella tua vita precedente eri un trancio di prosciutto?
cos'avevi fatto in quella prima? :) 

"andrea palazzi" ha scritto

Lavorava in MS...
Bye, G.

 numerici.
Il problema � che se fai questo con una tabella ok, ma se tutte le tabelle
han la doppia ricerca diventa un po' impegnativo a livello di GUI magari.
Comunque io ho parametrizzato le stampe mettendo in una combo i campi per
cui possono filtrare, e si scelgono quello che vogliono :)

 programmatore a programmatore!
Volevo fare un dibattito proprio su quello :)
E' che mi sto rendendo conto che nel master detail classico che ho non c'�
bisogno di far vedere tanti codici.
E' un lavoro analizzato a settembre e che dovrei far partire da ora, salvo
che non abbia da fare cose pi� urgenti.
Vediamo un po' di metterci le mani per bene.

 cos'avevi fatto in quella prima? :)
Magari.....
ero il povero cristo che prendeva l'nsalata scaduta la portava nel
retro supermercato...."scattivava" le foglie marce o "passate"...ve le
re-imbustava,,,e ve le ri.metteva sugli scaffali!
Dove VOI la compravate!!!
In quel per fortuna breve (un anno) periodo della mia vita sono
definitivamente diventato un carnivoro convinto!
;o)

On 30 Ott, 09:25, "Andrea [Work]"
<andrea.isworkDELET...@gmail.invalid> wrote:
spetta
calma
Testata Fattura --> Voci Fattura
Io uso un codice ....interno...il più possibile automatico e senza
problemi ...serve a me...per collegare uno a molti le voci della
fattura (io uso l'integrità referenziale  sempre...tranne rarissime
eccezioni!).
Mi serve per cancellare manualmente....per tenere dei log personali
etc etc
L'utonto non vede nulla di ciò! Cerca la testata per data e
cliente...o combinazioni varie...
Le singoli voci sono appannaggio di situazioni particolari e
sottoposte a tools costruiti ad hoc supervisionate da un responsabile
con privilegi superiori a un semplice operatore. E non dico altro
"capisci ammè"!!!
Un magazzino?
L'articolo avrà un codice ed una descrizoe sintetica...e se è
variegato una categoria
io ho l'esempio di un magazzino di termoidraulica
ci sono tubi di tutti i tipi...in rame ...polietilene...ghisa...etc
etc
di tutti i diametri...con caratteristiche diverse....
poi ci sono le pompe....sommerse....autoclavi...etc etc
poi i sanitari....le caldaie....un casino!!!
..e poi la minuteria....bulloni..rondelle...elettrodi per
saldature..etc etc
AL00138FG  Pompa sommersa Mod. Succhiotutto
secondo te l'utonto si ricorda AL00138FG?
ti rispondo io...si! L'ho visto....apre il cassetto sotto il
terminale...prende il quaderno liso e macchiato e trova le pompe da
vendere quel mese.....
"Mod.Succhiotutto???"....ditone...AL00138FG....lo scrive nel programma
di magazzino!!!  ROTFL se non fosse tragico!
E poi ci sono gli errori....Mod Succhio(r)utto???
AL000139FG...zam....errore impossibile da vedere!
La cosa allora per mia esperienza va rivoluzionata
AL00138FG Pompa Sommersa Mod Succhiotutto Produttore:PumpIT
Categoria: Pompe idrauliche etc etc
cerchi nella categoria pompe il mod.succhiotutto e clicchi su ADD
oppure ecco perchè il codice rimane (mai essere talebani!)....passa
l'operatore CLICK...spara il codice a barre e aggiunge il prodotto
MA COMUNQUE
nella mia tabella interna....detail se vuoi...io la chiamo slave
(master slave...reminescenze elettroniche!!!)...ci va il codice...che
spessisimo decido di NON mostrare!!!
Così i magazzinieri mi ringraziano alla lunga...anche se all'inizio ci
mettono più tempo a passare un pallet di prodotti (quelli che non
hanno la pistola laser ovvio!)...non son costretti a girare con il
taccuino dei codici!
Esperienze sempre e soltanto IMHO

 definitivamente diventato un carnivoro convinto!
Immagino che il collega, che lavorava la porta affianco, al reparto
carni, che TU compravi, sia diventato vegetariano per motivi
analoghi...

 subito di che si parla, ma dovrei gestire bene le integrit�
In questo caso meterei tutti e due i campi; uno servirebbe per parlare 
all'utente, e l'altro, solo numerico, per ordinare, confrontare, joinare 
sarebbe la vera chiave
-- 
Greg 

 definitivamente diventato un carnivoro convinto!
Vabb� � quello che fa anche il contadino.

 sarebbe la vera chiave
Si per� poi diventa noioso gestire che la doppia ricerca, perch� un cliente
usa i numeri e uno usa i codici. Comunque in quei casi � la soluzione
migliore mi sa.

 Esperienze sempre e soltanto IMHO
Bhe un magazziniere che non pu� fare carichi/scarichi con un barcode � un
martire a prescindere :)
Comunque poi nei casi particolari si fa anche una form di ricerca
personalizzata senza problemi.
Ad esempio nella parte di fatturazione ho un cliente che � anche un
ospedale, per cui nelle fatture invece degli articoli inserisce prestazioni
sanitarie (ecografia, RX, ecc.). Hanno una mascherina che gli permette di
richiamare le prestazioni.
Non essendoci poi esigenze di avere un articolo rimane la fattura
"descrittiva" senza problemi.

 articoli a memoria già userà il codice senza problemi.
zac
...mi rimane sempre il dubbio che un "magazziniere" che si ricorda
qualche migliaio di codici sia ASSOLUTAMENTE sprecato in quel ruolo!
capitasse a me...di professione...farei il giocatore di poker...o il
concorrente di quiz tv...
a mia esperienza il guaio è proprio quello...il magazziniere userà
solo i codici che si ricorda...un pianto ed un lamento li ho tolti
(visibili)...fa due click in più...ma non trovano più bolle con
l'articolo generico.
In un grande sistema c'è sempre un articolo generico a cui imputare il
pezzo che non passa sotto il laser perchè il codice è illeggibile o
non ancora inserito!
Io l'ho viste bolel in questo modo....o fatture di uno studio
medico...con "prestazione ambulatoriale" invece di ecografia!...il
codice si fa prima...se lo sai..se non lo sai...e l'impiegato è sotto
stress (perchè ha il camion che aspetta...o la sala piena...o il
capufficio come un avvoltoio dietro le spalle..o è a progetto per un
mese...)...se sei in questa situazione...a mia esperienza...9
impiegati su 10....mettono un generico codice!!!
(io stesso quando ero giovane e assunto in estate in sostituzione
ferie...alla cassa battevo "reparto 1" se i pelati o le patatine o le
zucchine...non passavano allo scanner!...m'importava sega! Si
incazzavano di più se vedevano fila!)
Ecco perchè (IMHO) un po dall'altra parte della barricata farebbe bene
stare ad alcuni miei "colleghi" (è generica questa frase eh!!!) !!!
Saluti!

 incazzavano di pi� se vedevano fila!)
Pensa che un ns. cliente ha fatto bloccare un codice articolo generico che
poteva essere utilizzato solo in alcuni casi, altrimenti in produzione si
trovavano ordini testuali senza sapere l'articolo preciso.
Comunque alla peggio fanno tutti i metodi di ricerca che il programma gli
permette.
Ho anche gente che non scrive mai articoli, ma usa le righe come excel.
Sulle piccole realt� � pi� che frequente.

"Andrea [Work]" <andrea.isw...@gmail.invalid> wrote in
news:1gv93b7jrh4r7.b0gu9cpq0m6f$.
d...@40tude.net
: 

imho dare all'utente, lato interfaccia, due dati univoci diversi per 
identificare lo stesso oggetto non e' una buona scelta.
per l'utente non mi pare ci siano vantaggi (no, 'sono abituati cosi' non 
vale; si, 'il capo ha DETTO cosi' va bene) e a te tocca piu' lavoro sia 
nell'interfaccia che in caso di debug o rogne (perche' ogni tanto ti 
chiamano dicendo il codice, ogni tanto l'id e qualche volta scambiano uno 
per l'altro anche se uno e' numerico e l'altro no).
intendiamoci, e' doveroso dare all'utente diversi modi di 'cercare'  
l'oggetto (per descrizione, per codice, per fornitore, etc), ma non modi 
diversi di 'identificare' lo stesso oggetto.
poi tu metti quanti id vuoi nelle tabelle, ma all'utente ne visualizzi 
sempre e solo uno.
e ovviamente sempre lo stesso!
:-)
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 e ovviamente sempre lo stesso!
Il codice spesso lo danno incompleto. Esempio mettono codice "RB" e l� ci
sono tutte le Ricevute Bancarie, scrivono RB e gli appaiono solo quelle.
C'� da dire che si ritorna al problema iniziale, cio�
 - decido io la chiave e loro se la devono ricordare per eventuali richiami
 - la faccio decidere a loro, ma devono non mettere codici duplicati ecc.
Per il problema del post, alla fine ho predisposto le tabelle con ID
increment.
Le 5/6 master/detail concatenate tanto sono ricercate a catena o per altri
campi che non potranno mai essere chiave.
Le altre tabelline accessorie ID,Descrizione classiche saranno usate
tramite combo senza che vedano neanche l'ID, o se proprio lo ricordano
glielo faccio scrivere per velocizzare, si parla di un numero di record
entro i 10/15 in ogni caso.
Giusto per completare il post, c'� da dire che gli auto increment sono
molto scomodi quando si prevede di trasferire e ricevere dati da DB
differenti, ma non penso sar� direttamente il caso (se non per qualche
tabella sincronizzata magari con un palmare).

 Tnx
Visto che ora sto cristonando su un progetto con db Oracle (che faceva
uso massiccio delle funzioni native di Oracle, con sequences,
integrità referenziale, cancellazioni a cascata, ecc) che stiamo
spostantdo su MySql (che, a quanto sembra, non supporta la
cancellazione a cascata), il mio atteggiamento e' di controllare a
manina tutto quello che viene scritto su db. Ogni tabella ha un campo
'id' pk numerico, che calcolo io quando scrivo e che mi serve per i
join con le tabelle di look-up e altro, e le cancellazioni me le
smazzo io nell'ordine che serve a me. In quwesto modo, qualsiasi db tu
abbia sotto la tua applicazione funziona (...ehm... almeno non ti
esplode ogni 3x2...)
Bye by SixaM 8-]