Esiste uno schema o una struttura logica che posso seguire per i numeri di registro degli eventi?

Avviso equivoco : presentare uno schema come questo richiederà una governance per mantenere lo schema utile.

Ho partecipato a numerosi progetti che utilizzano uno schema simile a quello che stai descrivendo. È molto utile per help desk, L2 e L3 quando lo schema viene applicato. Uno dei grandi vantaggi è che HD può rapidamente comunicare di trasmettere determinati messaggi e trasmetterli alla catena perché indicano problemi più gravi rispetto a quelli per cui sono stati addestrati.

Suggerirei di suddividere prima per area, poi per gravità.
Lasciati un sacco di spazio tra le aree principali in quanto è un vero PITA, se non addirittura impossibile, per spostare i numeri di errore intorno dopo che sono stati impostati. Non è una sfida tecnica, ma più di una sfida di documentazione e riqualificazione.

Uno schema semplice potrebbe essere questo:
- 1000 appartengono a "messaggi dell'applicazione di base"
- 2.000 appartengono a IO
- 3.000 appartengono a DB Comms
...
- 9.000 appartengono a brutte ansie che richiedono un'indagine L3 immediata

dove ciascuno dei blocchi è un'area principale della tua applicazione. Interfaccia utente / Ganci DB / Config mgmt / file IO / etc ... sono solo alcuni esempi di aree che potrebbero ricevere il proprio blocco di numeri di messaggi.

All'interno di quei gruppi:
0 - 250 sono informativi 251 - 500 sono avvisi
501 - 750 sono errori
751 - 999 sono debug / trace (presupponendo che tu non abbia una struttura separata per quello)

Se è possibile utilizzare un indicatore di lettere alla fine del messaggio, è possibile saltare questo sottogruppo di gravità. Ma non tutti i meccanismi di archiviazione degli eventi consentono l'utilizzo di un carattere non numerico.
Un'altra opzione sarebbe quella di utilizzare l'ultima cifra del messaggio per indicare la gravità. In altre parole, i numeri di errore che terminano con 0,1,2 sono Info, ... 8,9 sono debug / sky-is-falling.

Ovviamente, soddisfa i numeri e gli intervalli in base alle tue esigenze, i precedenti sono solo esempi.

Questo è un layout simile ma diverso da Codici di errore HTTP .
Con la differenza principale è che si tratta di un'area applicativa che guida l'organizzazione / l'assegnazione di numeri di messaggi di errore. I codici HTTP non hanno realmente aree applicative in grado di distruggere le cose.

Non sono un grande fan semplicemente usando numeri sequenziali o usando il conteggio dei salti. Prima di tutto, non esiste una struttura logica per questi schemi e fornisce solo un suggerimento su quando i messaggi sono stati creati. Sapendo che 0010 è stato creato come messaggio di errore molto prima che il messaggio 750 sia praticamente privo di informazioni.
Metterei un voto per l'organizzazione logica anche all'interno delle categorie info / warning / error, ma questo può diventare molto difficile o complicato da mantenere.

usa un ordinamento sequenziale standard per EventID, se vuoi distinguere tra i livelli di registrazione usa una colonna separata. La tua idea alternativa viola il primo modulo normale e renderebbe la creazione di query filtrate per tipo molto più difficile di quanto sia necessario.

L'ID evento, insieme alla Sorgente, dovrebbe identificare in modo univoco ogni evento. Ciò significa che la persona di supporto quando ha detto al sorgente / numero deve sapere quale errore si è verificato e i passaggi da seguire per risolverlo.

Usiamo una tabella di ricerca nel nostro database che memorizza Numero, Descrizione, Tipo, Gravità. In questo modo il personale di supporto può cercare un numero (ad esempio 5000) e sapere che significa "record bloccato da un altro utente". Crea un numero per ogni eccezione nota e il supporto diventa molto più semplice.

Raccomando strongmente di non usare numeri sequenziali se non vi è alcun altro significato assegnato a loro. Ciò non fornirà ulteriori informazioni al personale dell'help desk.

Penso che una combinazione di sequenziale con un prefisso indichi la categoria & la gravità potrebbe essere buona. Potresti avere le prime 2 (o 3) cifre per gravità, le prossime per categoria e poi un numero sequenziale. L'intera stringa indica il tipo di problema e può essere facilmente rintracciabile nel file di registro. Il problema è che nel tuo codice ora hai 3 numeri da registrare al posto di uno (se dovessi usare solo un numero sequenziale). Se è possibile utilizzare anche caratteri alfabetici (come "E", "I", "W") potrebbe essere utile.

Se accedi a una tabella anziché a un file, la categoria, la gravità e così via dovrebbero essere in colonne separate dall'ID.

Incremento sequenziale di 10, ma non utilizzare la colonna 1s finché non è necessario. È una (molto) semplice salvaguardia per la granularità futura e il raggruppamento di eventi simili.

Ad esempio, abbiamo stati 100 per "nuovo record", 200 per "in corso", 300 per "inviato" e così via.

Recentemente, 210, 220 e 230 sono stati aggiunti perché sono stati introdotti ulteriori passaggi nel processo di modifica. Poiché abbiamo lasciato degli spazi negli ID, siamo stati in grado di inserirli in un posto logico - l'intervallo 2 * ha tutti a che fare con "in corso" in qualche modo.

Ma queste aggiunte tendono ad essere rare, motivo per cui suggerisco di usare 10 secondi invece di 100 come abbiamo fatto noi.

Le query per "stati in corso" sono quindi un semplice BETWEEN 200 AND 299 . (oppure, 20 e 29 se usi 10 secondi)