Gestione Campi ID/Codice

[Andrea [Work]]

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

[The man with two watches]

"Andrea [Work]"
[...]
> Avete qualche consiglio?
> 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

[Andrea [Work]]

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 :)

[Wodka40[Google]]

On 26 Ago, 16:31, "Andrea [Work]"
<andrea.isworkDELET...@gmail.invalid> wrote:
zac

>
> 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?

:)

[Andrea [Work]]

Il Sat, 29 Aug 2009 01:21:04 -0700 (PDT), Wodka40[Google] ha scritto:

> Ed allora....perch� vuoi un codice?

> Un codice che l'uTonto veda e imputi/modifichi?
> E' indispensabile?

Una segretaria che fa 30/50 bolle al giorno, se deve mettere un codice
pagamento, e sa che facendo 10 invio gli prende quello � una comodit�
richiesta.
Non sempre cercare fra 10/100 codici di pagamento � comodo.

> 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?

E' sicuramente fattibile, ma in alcuni ambiti non � detto che sia comodo.

> 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

Ho un cliente che ha prodotti di vinificazione, ha codificato i codici in
base all'annata, esempio 05BM vuol dire brunello montalcino 2005.
Hanno anagrafiche boh, di qualche centinaio o migliaio di prodotti,
filtrarli subito per qualcosa che sanno nel codici � importante.
Far apparire una maschera di filtro che gli fa filtrare tutti gli articoli
� "lento" per loro.

> 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?

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 :)

[Paolo opg]

"Andrea [Work]" <andrea.isw...@gmail.invalid> wrote in
news:1k6sqsymetkjf$.kmnxhxzele82$.d...@40tude.net:

[cut]

>
> 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.
>

se ho capito quello che intendi, questa e' principalmente una tua scelta di
progetto, che ha relativamente poco a che fare con le richieste del
cliente.

se scegli di registrare un dato nel db e di presentarlo a video formattato
in altra maniera, il cliente c'entra poco, dato che il cliente non vede
direttamente il contenuto del db.

anni fa c'erano limiti ai caratteri gestibili dai motori db o dalle
librerie, ma con gli strumenti attuali non ci dovrebbero essere problemi a
salvare (quasi) tutti i caratteri direttamente in tabella, eliminando la
necessita' di formattare l'output per soddisfare le richieste estetiche del
cliente.

poi ci sono i casi particolari, ma queste sono considerazioni generali,
giusto?
:-)

> 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.
>

riguardo il progressivo, perche' *devi* gestirlo?
ci sono casi in cui e' necessario (requisiti di legge o imposizioni del
cliente), ma imho non e' per niente un must.
(n.b.: io interpreto 'codice progressivo' come 'codice composto con numeri
in sequenza e senza buchi'. e' quello che intendi?)

soprattutto se c'e' la possibilita' dell'inserimento manuale del codice da
parte dell'utente, il progressivo va a farsi friggere...

puoi 'suggerire' il prossimo codice (prendi la parte numerica, max e
aggiungi 1, tanto per dirne una), ma niente di piu'.

in una anagrafica clienti, cosa cambia se i codici sono in sequenza o no?

nell'anagrafica dei metodi di pagamenti a cui accenni nel primo post, il
progressivo non esiste proprio dato che i codici sono parlanti...

> 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...
>

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
--

[Andrea [Work]]

Il Mon, 31 Aug 2009 12:56:04 +0000 (UTC), Paolo opg ha scritto:

> se ho capito quello che intendi, questa e' principalmente una tua scelta di
> progetto, che ha relativamente poco a che fare con le richieste del
> cliente.
>
> se scegli di registrare un dato nel db e di presentarlo a video formattato
> in altra maniera, il cliente c'entra poco, dato che il cliente non vede
> direttamente il contenuto del db.

E' quello che voglio evitare.
Ce l'ho attualmente con un campo, e devi fare funzioni di co/decodifica.
Sia nelle maschere, sia nelle stampe ecc.
Una cosa noiosissima.

> riguardo il progressivo, perche' *devi* gestirlo?
> ci sono casi in cui e' necessario (requisiti di legge o imposizioni del
> cliente), ma imho non e' per niente un must.
> (n.b.: io interpreto 'codice progressivo' come 'codice composto con numeri
> in sequenza e senza buchi'. e' quello che intendi?)

Allora un cliente mi dice: "voglio inserire 20 record in questa tabella
(es. articoli), ma il codice voglio me lo dia il programma"
Altrimenti il cliente dovrebbe vedersi il primo numero libero, e
associarlo ecc.

> soprattutto se c'e' la possibilita' dell'inserimento manuale del codice da
> parte dell'utente, il progressivo va a farsi friggere...

Appunto, ma io non volevo vincolare il cliente a gestire i codici a numero
auto_increment come c'� adesso (ok, ci sono accoppiati anche campi
"codice", ma a quel punto devi fare le ricerche doppie)
Per� se uno non vuol pensare al codice, qualche modalit� ci deve essere.

> puoi 'suggerire' il prossimo codice (prendi la parte numerica, max e
> aggiungi 1, tanto per dirne una), ma niente di piu'.

Esatto.

> in una anagrafica clienti, cosa cambia se i codici sono in sequenza o no?

In una tabella del genere niente, supponiamo una tabella articoli, o
qualche altra cosa in cui vogliono vedere ordinato per codice.

> nell'anagrafica dei metodi di pagamenti a cui accenni nel primo post, il
> progressivo non esiste proprio dato che i codici sono parlanti...

Sostanzialmente io volevo lasciare all'utente la possibilit� di scegliersi
l'identificativo per quel record. Che sar� il campo che vedr� stampato, o
quello per cui ricercher� (oltre alle ricerche per nome).

> 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?

Oddio una select max, con firebird non � proprio il max, ma comunque si pu�
fare su tabelle piccole.

> il quarto punto, ricade nel commento iniziale; con gli strumenti attuali,
> 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.

[Paolo opg]

"Andrea [Work]" <andrea.isw...@gmail.invalid> wrote in

news:10xhfdaktmg7z.l9utat32g1v6$.d...@40tude.net:

> Il Mon, 31 Aug 2009 12:56:04 +0000 (UTC), Paolo opg ha scritto:
>
>> se ho capito quello che intendi, questa e' principalmente una tua
>> scelta di progetto, che ha relativamente poco a che fare con le
>> richieste del cliente.
>>
>> se scegli di registrare un dato nel db e di presentarlo a video
>> formattato in altra maniera, il cliente c'entra poco, dato che il
>> cliente non vede direttamente il contenuto del db.
>
> E' quello che voglio evitare.
> Ce l'ho attualmente con un campo, e devi fare funzioni di
> co/decodifica. Sia nelle maschere, sia nelle stampe ecc.
> Una cosa noiosissima.
>

mi sono perso.
vuoi evitare... cosa?
se salvi il codice nel formato giusto nel db (con tutti i fronzolini voluti
dall'utente), non hai da co/decodificare niente.
dall'interfaccia leggi il contenuto del campo e quello presenti all'utente
cosi' com'e'.

>
>> riguardo il progressivo, perche' *devi* gestirlo?
>> ci sono casi in cui e' necessario (requisiti di legge o imposizioni
>> del cliente), ma imho non e' per niente un must.
>> (n.b.: io interpreto 'codice progressivo' come 'codice composto con
>> numeri in sequenza e senza buchi'. e' quello che intendi?)
>
> Allora un cliente mi dice: "voglio inserire 20 record in questa
> tabella (es. articoli), ma il codice voglio me lo dia il programma"
> Altrimenti il cliente dovrebbe vedersi il primo numero libero, e
> associarlo ecc.
>

creo una sp 'suggerisciCodice' che genera id casuali per quella data
tabella.
creo una sp 'inserisciRecord' che richiama la 'suggerisciCodice'.
creo una sp 'inserisciBulk' che richiama N volte la 'inserisciRecord'.
richiamo la inserisciBulk passandole i dati delle 20 righe e il gioco e'
fatto; il progressivo non l'ho utilizzato.

e' un problema delle funzioni di supporto all'interfaccia, non della
struttura del db.

>> soprattutto se c'e' la possibilita' dell'inserimento manuale del
>> codice da parte dell'utente, il progressivo va a farsi friggere...
>
> Appunto, ma io non volevo vincolare il cliente a gestire i codici a
> numero auto_increment come c'� adesso (ok, ci sono accoppiati anche
> campi "codice", ma a quel punto devi fare le ricerche doppie)
> Per� se uno non vuol pensare al codice, qualche modalit� ci deve
> essere.
>
>> puoi 'suggerire' il prossimo codice (prendi la parte numerica, max e
>> aggiungi 1, tanto per dirne una), ma niente di piu'.
>
> Esatto.
>
>> in una anagrafica clienti, cosa cambia se i codici sono in sequenza o
>> no?
>
> In una tabella del genere niente, supponiamo una tabella articoli, o
> qualche altra cosa in cui vogliono vedere ordinato per codice.
>

l'ordinamento si fa sempre, quale che sia il metodo con cui generi il
codice; sia che lo metta a manella l'utente o che sia generato da qualche
funzione, poi puoi sempre ordinare per quel dato campo (ok, se e' un blob
non si puo'...).

pero' e' un problema lato interfaccia o degli indici da creare, ma che non
obbliga ad avere codici consecutivi o numerici o a evitare che ci siano
buchi nella numerazione.

al massimo c'e' il fatto che al cliente possano non piacere i buchi nella
numerazione quando fa la stampa...

[cut]

>> il quarto punto, ricade nel commento iniziale; con gli strumenti
>> attuali, 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.

[Andrea [Work]]

Il Mon, 31 Aug 2009 15:51:54 +0000 (UTC), Paolo opg ha scritto:

> mi sono perso.
> vuoi evitare... cosa?
> se salvi il codice nel formato giusto nel db (con tutti i fronzolini voluti
> dall'utente), non hai da co/decodificare niente.
> dall'interfaccia leggi il contenuto del campo e quello presenti all'utente
> cosi' com'e'.

Allora attualmente ho due tabelle con codici (cliente) che nel DB sono
salvati come C00001, mentre per facilitare l'utente in interfaccia e in
stampa utilizza sempre C/1 ecc.
Questo implica che quando estraggo i dati devo convertire in C/1 quando
salvo devo rimettere C00001.
Questo sicuramente non voglio pi� farlo in futuro.

> creo una sp 'suggerisciCodice' che genera id casuali per quella data
> tabella.
> creo una sp 'inserisciRecord' che richiama la 'suggerisciCodice'.
> creo una sp 'inserisciBulk' che richiama N volte la 'inserisciRecord'.
> richiamo la inserisciBulk passandole i dati delle 20 righe e il gioco e'
> fatto; il progressivo non l'ho utilizzato.
>
> e' un problema delle funzioni di supporto all'interfaccia, non della
> struttura del db.

Si � un problema di interfaccia, ma appunto voglio che i codici siano
visualizzati cos� come sono.
D'altro canto far gestire all'utente codici tipo 00000000001 diventa un po'
noioso.
Se mi vuol fare una stampa della tabella che ha quel campo con quel valore,
deve scrivere nel filtro 00000000001, che � ben pi� scomodo da scrivere
rispetto a 1.

Il mio dubbio era di come sostituire funzionalmente gli auto_increment,
lasciando la possibilit� all'utente di scegliersi i codici qualora lo
volesse.

Ovviamente se il cliente si mette i codici che vuole poi sono affari suoi.

> 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.

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

[Paolo opg]

"Andrea [Work]" <andrea.isw...@gmail.invalid> wrote in

news:1wbi6boz88899$.10l6b5jg...@40tude.net:

[cut]

>
> Si � un problema di interfaccia, ma appunto voglio che i codici siano
> visualizzati cos� come sono.
> D'altro canto far gestire all'utente codici tipo 00000000001 diventa
> un po' noioso.
> Se mi vuol fare una stampa della tabella che ha quel campo con quel
> valore, deve scrivere nel filtro 00000000001, che � ben pi� scomodo da
> scrivere rispetto a 1.
>

spesso in fase di ricerca l'utente inserisce solo qualche carattere
(massimo 4 o 5) del codice, clicca sul pulsante 'trova' e poi sceglie
dalla lista.

con un codice corto, e' vero che l'utente va a memoria e il risultato della
ricerca sara' un solo articolo/record, ma con funzioni di ricerca pensate
con un po' di criterio, anche codici piu' lunghi non creano problemi.

[cut]

>
> 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

[Andrea [Work]]

Il Tue, 1 Sep 2009 08:03:08 +0000 (UTC), Paolo opg ha scritto:

> spesso in fase di ricerca l'utente inserisce solo qualche carattere
> (massimo 4 o 5) del codice, clicca sul pulsante 'trova' e poi sceglie
> dalla lista.
>
> con un codice corto, e' vero che l'utente va a memoria e il risultato della
> ricerca sara' un solo articolo/record, ma con funzioni di ricerca pensate
> con un po' di criterio, anche codici piu' lunghi non creano problemi.

Questo � vero, per� in alcuni casi scrivere il codice subito � molto
comodo.
Pensiamo ad un utente che inserisce centinaia di quei record al giorno, e
scrivere "2 > Invio" piuttosto che "000 > Trova > seleziona 0002".
Comunque � assolutamente vero che se i codici sono ricordati a mente, vuol
dire che siamo nell'ordine dei 20/30 codici per tabella. Quindi in quei
casi un codice di 3 caratteri tipo 001 non lo vedo un problema.
Se � una tabella pi� complessa viene sempre messo parte del codice e basta,
anche perch� la lunghezza di questo � direttamente proporzionale di solito
al numero di record della tabella.

> 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

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.