Newsgroup: it.comp.software.database
Titolo: Gestione Campi ID/Codice

Salve a tutti,
devo sviluppare un piccolo applicativo, e vorrei orientarmi diversamente
per quanto riguarda i campi chiave.
Volevo abbandonare ove possibile i "comodi" auto-increment e passare a dei
campi alfanumerici es. di #n caratteri.
Con questo approccio mi scontro con 2 problemi:
L'utente potrebbe volere una gestione "auto increment", e su un varchar
dovrei memorizzarli come 0000001 per fare gli ordinamenti corretti. Col
problema di far vedere una cosa "1" e memorizzarne un'altra "0000001".
Inoltre devo appunto prevedere che un codice nuovo sia proposto subito in
qualche modo. Esempio A000001 ecc. senza tornare al problama del punto 1).
D'altro canto un codice alfanumerico � "pi� parlante" di un auto-inc.
Esempio il pagamento id=<120> o id="RB3060", col secondo sai gi� che
pagamento �, col primo devi conoscere a memoria la tabella, o leggere la
descrizione associata da qualche parte.
Inoltre in ottica trasferimento record fra DB, gli autoincrement sono pi�
rognosi da gestire, i campi generati si gestiscono molto meglio.
Esempio se 2 archivi devono condividere un'anagrafica articoli, se in uno
dei due ho per qualche motivo un articolo in pi�, i numeri non
corrispondono mai.
Avete qualche consiglio?
Tnx

 Tnx
Sostanzialmente le considerazioni che fai sono giuste spec. il
discorso dell'integrazione tra db diversi, nei quali un po' di
verbosita` extra viene ben tollerata in cambio di facilita` di
scambio dati.
Non usare autoID impone alcuni oneri di gestione in piu`, ma che
possono venir ripagati dalla flessibilita` di poter creare
schemi di numerazione personalizzati.
Pertanto rimane solo da decidersi e farlo :-)
Al limite sconsiglierei di usare un varchar, per stringhe cosi'
brevi viene piu' facilmente gestito un CHAR; tanto si fa sempre
in tempo ad ampliarne i caratteri o cambiare il tipo.
bye 



Ok, quindi un CHAR(10) dovrebbe andar meglio.
Il mio problema � che NON VOGLIO fare come i codici cliente che l'utente
vede e scrive sempre C/1, C/2, mentre nel DB sono memorizzati C00001 per
avere la possibilit� di order by ecc.
Questo implica di fare conversioni in ogni parti del programma, nelle
stampe ecc.
Certo forse si risolveva con un campo "CODICE_ORDER" formattato per
l'ordinamento.
Quel campo comunque non � modificabile dall'utente, ha quella struttura
fissa, e devo inoltre gestirmi una sorta di progressivo.
Pensare di fargli scrivere a loro i codici probabilmente � utopia, sarebbe
troppo bello che facessero tutto da soli (magari su tabelle da 10/20
recordo si).
Al contempo se converto io i dati (da "1" a "0000001") loro perdono ogni
possibilit� di customizzazione, oppure se gliela lascio io non posso pi�
ricavarmi un progressivo.
Insomma non vorrei alla fine fosse pi� un esercizio di stile con pi� contro
che pro.
Una cosa fattibile sarebbe 
1) tabella esterna con progressivi per tabella (sorta di generator)
2) propongo il valore di quel numero di generatore, e se usano quello mando
avanti il progressivo per inserimenti futuri
3) se customizzano allora vuol dire che i codici se li gestiscono da soli
4) rimane il fatto di far scrivere e vedere "1" e salvare magari "000001".
Questo si risolve con un campo "CODICE_ORDER" in ogni tabella dove mi
memorizzo il codice con 0000 iniziali se � un numero, altrimenti col codice
inputato "A/546".
Mi sembra un po' troppo intricato, anche perch� se io mi faccio i codici da
solo e scrivo A/2 o A/100, mi aspetto che il primo venga stampato prima del
secondo...
Ma forse sto delirando :)

 Ma forse sto delirando :)
Insomma...il caldo un po si fa sentire!
Il problema imho di un analista programmatore ...è quello di smettere
di essere un ingegnere (ogni tanto)...e di pensare/penare dalla parte
dell'utente!
Ed allora....perchè vuoi un codice?
Un codice che l'uTonto veda e imputi/modifichi?
E' indispensabile?
E' indispensabile perchè non cè nulla di "visual"... si fà tutto da
tastiera ...e con i ricordo del "codice della pratica"? ....in questo
caso pianifica anche che non tutti gli uTonti sono "svegli" e
"memonici"...e che comunque l'addestramento prenderà più ore!
Un sistema...clicco sulla riga...o sull'icona...o seleziono più
righe...o cerco con un motore interno...e non faccio vedere codici (o
se li faccio vedere sono solo per bellezza)...non è fattibile?
Mi dirai...in una gestione articoli magazzino no!
Beh sarebbe da discutere (più che altro sono limitazioni che ci si
tira dietro da mainframe costosi che l'azienda non ha voglia di
aggiornare/sostituire!...o da strutture che oramai "si fà così"...e
"così" si continuerà a fare in eterno!)
Comunque da mia esperienza
Codice alfanumerico...lettere e cifre...le lettere indicano
qualcosa...i numeri sono il progressivo
Tipo
FIAPZR0003425
F= Fornitore
I= Italia
A= Magazzino A
XXX=categoria es PZR pezzi ricambio
nnnnnnn= numero articolo
....mi sembra assurdo in un epoca di db ad alte prestazioni ancora
infognarsi nei "codici parlanti"...ma tant'è!...questo sistema lo usa
il mio amico architetto  per catalogarsi con un mdb + file system le
centinaia di pratiche che ha....ma lui è un architetto....lontano anni
luce da un ingegnere.
IMHO
Prevedigli un po di char...e poi scrivi una funzione per assegnare i
progressivi...
Io cerco di dimostrare che non ha senso ordinare per numero di codice
PZ0001  Bullone d.12
PZ0002  Bullone d.10
PZ0003  Bullone d.32
PZ0004  Bullone d.8
che senso ha?
:)

 che senso ha?
In questo caso nessuno, ma pi� di un cliente mi ha chiamato quando ha visto
stampe ordinate come: 1, 10, 100, 2, 20, 3, 30 ecc. pur avendo chiesto
l'ordinamento per quel campo (il campo non era numeric ovviamente).
Che poi di solito telefonino solo per rompere le scatole �  un altro
discorso, e lo sappiamo bene :)

 
io probabilmente ho solo situazioni 'semplici', ma perche' tabella 
d'appoggio per la generazione dell'id?
a che pro registrare in una posizione separata il duplicato di 
un'informazione che ho gia' nella tabella contenente i dati?
performances in caso di database di grosse dimensioni?
il quarto punto, ricade nel commento iniziale; con gli strumenti attuali, 
la scelta di cosa registrare nel db, e' principalmente tecnica, imho.
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 la scelta di cosa registrare nel db, e' principalmente tecnica, imho.
Il discorso � venuto fuori per non obbligare il cliente ad avere solo un
auto_increment per ricordare qual era il record.
Solo che se voglio evitargli di fargli scrivere "0000000001" per scrivere
il codice 1.

 
anche qui, mi sembra piu' che altro un problema di interfaccia.
se la ricerca nel db la fai tramite stored procedure, qualsiasi casella 
ficchi nell'interfaccia richiamera' sempre la stessa stored.
l'utente inserisce l'input nella forma che preferisce, l'interfaccia passa 
l'input alla stored e la stored lo 'normalizza'; a questo punto, dato che 
hai un unico punto d'accesso, e' abbastanza semplice avere del codice che 
preveda tutti i fronzoli che l'utente potrebbe inventarsi e li gestisce 
come si deve, digerendo senza troppi problemi anche il caso che hai 
descritto.
imho alla fine devi vedere principalmente se in fase di inserimento record 
c'e' input manuale del codice oppure no.
se c'e', ti crei una funzione 'suggerisciCodice', giusto per dare 
all'utente una possibilita' di avere un aiuto, e tanti saluti a codici 
sequenziali (la fantasia dell'utente e' notoriamente illimitata ^^).
se invece il codice lo generi tu, un autoincrementante o un indice casuale 
pari sono, almeno dal punto di vista funzionale.


 descritto.
Si � un discorso di interfaccia principalmente. Il DB salva tutto quello
che gli dico senza problemi :)
Forse non sono andato dritto al problema, che alla fine si riduce ad un
consiglio su come "proporre" una nomenclatura di codice standard
Quanti caratteri farlo (troppo grande diventa scomodo da inputare, piccolo
potrebbe essere limitato).
Quale regola posso seguire in base alle vs. esperienze, tenendo conto che
l'utente quel codice dovr� scriverlo in varie parti dell'interfaccia.
Se ad esempio farli 00001, 00002, oppure con un prefisso es. CI001, CI002.
Ribadisco ovviamente se il cliente si da una numerazione sua si gestisce il
tutto come vuole, anche se scrive 1,10,2,20,3 cavoli suoi a quel punto.
Ovviamente poi al salvataggio sar� gestito il discorso di ID Duplicati (che
sono PK), e la proposta del nuovo codice.
E' che presumo che alla fine il 90% user� i codici proposti, perch� sono
gi� abituati cos�.
Grazie

 
io di solito faccio una stima di quante righe potrebbero finire in tabella, 
raddoppio e dimensiono di conseguenza, se l'id non e' numerico.
se e' numerico, di solito un integer mi va bene per quasi tutto.
riguardo il formato, se puoi scegliere tu, trova la cosa piu' facile da 
gestire, altrimenti metti qualche paletto (tipo la lunghezza massima del 
codice) e chiedi al cliente cosa gli piace di piu' o se ha qualche idea e 
preparati alle risposte piu' fantasiose
;-P


 preparati alle risposte piu' fantasiose
Penso che siamo arrivati al dunque.
Posso mettere in configurazione del programma di quanto far grandi i
codici, in base a quello genero come 001 ecc. Lasciando comunque a l'utente
la possibilit� di far come vuole. Se mi scrive "1" poi cavoli suoi.
Poi nel DB i campi gli faccio es. tutti CHAR(10), giusto per avere la
flessibilit� dovuta e uno spreco di spazio non esagerato.