Come progettare un buon numero di ricevuta [chiuso]

A meno che la codifica delle informazioni aggiuntive non sia utile per scopi che non hai descritto nella tua domanda, non tentare di creare alcun tipo di intelligenza nei tuoi numeri. Alla fine si ritorcerà contro, spesso in un modo che renderà il recupero difficile e costoso.

Il mio consiglio? Usa un numero intero di sequenza e fallo con esso. Sono facili da gestire e, se li si utilizza come identificativi in un database, vengono archiviati in modo compatto e indicizzati molto più rapidamente rispetto alle stringhe.

As short as possible

Se in realtà stai facendo solo 10.000 transazioni al giorno, avrai tre zeri inutili in ogni numero di scontrino praticamente per sempre. Questo rende i tuoi numeri il 30% più grandi di quanto debbano essere. Più cifre aumentano le probabilità che ci sia una comunicazione o un errore di battitura. Qualcuno che non ha familiarità con il tuo schema non saprà che ci dovrebbero essere sette cifre nel tuo numero di sequenza e dovrà contare una serie di zeri iniziali per le ricevute con numero basso - ne avrai un sacco di quelle quotidianamente - e questo consumerà più tempo di quello che salverà.

Un numero intero di sequenza non durerà più finché non esaurisce le cifre nella sua dimensione attuale e può crescere praticamente all'infinito. I giorni in cui si esegue un volume basso ritarderanno l'aggiunta di cifre.

Somewhat not to obvious (YYYMMdd is way to obvious).

Non pensare per un minuto che qualcuno che vuole fare qualcosa di nefasto con i numeri di ricevuta non guarderà il suo calendario e noterà che stai usando l'anno e il giorno di Julian. Se il numero di ricevuta è l'unico metodo per verificare che qualcuno che te lo consegna sia il cliente che lo ha ricevuto, ti verrà compromesso. Gli amatori modellano i sistemi, i professionisti incastrano le persone.

Should be fixed length. (Easier to detect if customer entered invalid receipt number)

Non è davvero più semplice; se il numero non è nel tuo database, non è valido. C'è un sacco di potenziale per qualcuno di inserire un numero non valido che è la lunghezza giusta.

Can generate fairly large numbers (10 million a day seems sensible, though I doubt my system will be that popular)

Un numero intero senza segno a 64 bit può contenere un valore massimo di 9.223.372.036.854.775.807. Questo ti darà un miliardo di numeri unici al giorno per i prossimi 2,5 milioni di anni, più a lungo se non stai facendo questo tipo di volume.

Can be made into QR code (so staff can scan and verify the number is valid)

L'uso delle cifre assicura che sarai in grado di utilizzare qualsiasi formato di codice a barre. I codici a barre lineari eseguono una scansione molto più veloce di QR e sono leggibili in condizioni molto peggiori. Questo dovrebbe essere preso in considerazione se c'è un magazzino coinvolto.

Senza ulteriori informazioni sembra ragionevole, se non eccessivamente complesso. Nessuno qui può dire per certo che soddisferà i tuoi bisogni, poiché non hai detto quello che sono.

Cosa c'è di sbagliato con un numero sequenziale a partire da 0? - Dichiari "pensi che non sia abbastanza buono", quale requisito non soddisfa ?.

Cosa succede dopo il 2099 - qual è il requisito, cosa succede dopo 9.999.999 transazioni in un giorno - qual è il requisito, 'E' - quale requisito soddisfa?

Vorrei aggiungere una cifra di checksum. Rende più facile capire se qualcuno lo scrive e commette un errore.

Molti sistemi genereranno questi numeri contemporaneamente? Se è così, allora né il tuo sistema né i numeri sequenziali saranno sufficienti; ci saranno giorni in cui Internet non funziona, o un bug da qualche parte provoca collisioni e così via. Se queste cose sono vere, utilizzerei un GUID (che è "abbastanza unico"). Se i GUID non sono un'opzione, passerei all'esagono e userei una stringa numerica semantica come questa:

EDDDDLLLLNNNNNNNNC

Dove E è il tuo flag generico "Ho fatto questo", D è una stringa esadecimale che rappresenta l'anno e la data in esadecimale, L è una stringa esadecimale che rappresenta la posizione di origine (che consente 65.000 sistemi POS separati o altre fonti per utilizzare il sistema senza collisione), N è un numero di sequenza semplice per tale origine e C è una cifra di controllo.

Un esempio:

E3FDF00A2000000D2C

3FDF rappresenta 16351 , o il 12 giugno 2051. 00A2 rappresenta il tuo sistema POS. Il 000000D2 rappresenta il numero di sequenza del giorno e C è una cifra di controllo (calcolata semplicemente come (3FDF + A2 + D2) % F , che potrebbe non essere algoritmicamente perfetta).

Se sei disposto a rilassare il requisito che sia sempre della stessa lunghezza, puoi facilmente renderlo elastico, in modo che quanto sopra sia visualizzato come:

E3FDF00A2D2C

Le prime 9 cifre sono sempre le stesse e l'ultima cifra è la cifra di controllo, quindi il resto è il numero di sequenza. Se sei aperto ad avere un personaggio divisorio, potresti renderlo ancora più breve:

E3FDFA2-D2C