Mantenere sincronizzato un enum e una tabella


11

Sto realizzando un programma che pubblicherà i dati in un database e mi imbatto in uno schema che sono sicuro sia familiare: una breve tabella di valori fissi molto probabilmente (molto probabilmente) che fungono da enum. Supponiamo quindi che la seguente tabella abbia chiamato Status:

  Stato
  Descrizione ID
  --------------
   0 Non elaborato
   1 in sospeso
   2 elaborati
   3 Errore

Nel mio programma devo determinare un ID di stato per un'altra tabella o eventualmente aggiornare un record con un nuovo ID di stato.

Potrei codificare l'ID di stato in un enum e spero che nessuno cambi mai il database. Oppure potrei pre-recuperare i valori in base alla descrizione (quindi hardcoding che invece).

Quale sarebbe l'approccio corretto per mantenere questi due, enum e table, sincronizzati?


Perché mantieni le cose sincronizzate e non sincronizzate? Synch (dirlo) è strano!
MrFox,

1
@suslik Sono entrambi pronunciati allo stesso modo. Sincronizza e sincronizza .
MPelletier,

1
Avere un enum e la tabella del database è una duplicazione. A meno che la tabella del database non sia utilizzata da altre applicazioni, rinuncerei alla tabella e utilizzerei semplicemente l'enum. Se la tabella verrà utilizzata in più app, caricare invece gli stati dal database in fase di esecuzione.
Peter Smith,

Dipende dal contesto. In questo caso, essendo valori del flusso di lavoro o dello stato delle attività, tenderei a preferirli più dinamici rispetto a quelli statici, poiché i processi tendono spesso a cambiare; e tendono a cambiare fuori banda per i programmi di rilascio del software. D'altra parte, se si tratta di un servizio stabile che è improbabile che vengano introdotti nuovi stati o che vengano rimossi stati esistenti, potrei essere più costretto a codificare l'enum / denormalizzarli (a seconda di come i record verranno utilizzati in seguito).
Giustino

@PeterSmith Il database non può imporre vincoli se sono solo nel tuo enum Java e non in una tabella. Vincolerai i valori nel tuo database, vero?
David Conrad,

Risposte:


5

Vorrei codificare l'enum all'interno del tuo programma, poiché sospetto che questi diversi stati influenzino la logica dei tuoi programmi. Se hai un nuovo stato, come dovrebbe reagire il tuo programma a questo nuovo stato?

Poiché il database fa parte della tua applicazione, non penso che abbia senso influenzarne uno senza consultare l'altro, in un certo senso.


Non si tratta tanto di nuovi stati (che giustificherebbe sicuramente una modifica sia del database che del programma), ma dei valori ID.
MPelletier,

2
Non vedo perché cambieresti il ​​valore ID senza cambiarne il significato. Questo tipo di enumerazioni non verrebbe incrementato automaticamente, e queste sono in realtà solo per la leggibilità per le persone che eseguono il debug del database, poiché in genere l'applicazione farà query e saprebbe già quale sarà l'ID pending. Ovviamente avere una Statustabella ti dà integrità referenziale, ma questo è il punto che sto cercando di chiarire.
Matteo,

Bene sì, questa è l'idea. Ma se ho impostato gli ID su un posto e su altri, sto lavorando sul presupposto che entrambi abbiano ragione. È un collegamento sciolto, no?
MPelletier,

3
Facciamo sempre queste ipotesi, se si pensa a una definizione di tabella, il nostro programma presume che la definizione sia tale quando si scrive una query. La Statustabella non dovrebbe essere considerata dinamica durante il runtime dell'applicazione, e quindi non credo che dovresti leggerla come tale.
Matteo,

8

Normalmente caricare questi dati in una cache statica (di solito in una HashMap o qualcosa del genere) all'avvio dell'applicazione. Evita di dover ricompilare solo perché l'enum è stato modificato in qualche modo.


2

Poiché si tratta di stati, è necessario codificarli nell'applicazione per garantire che nessuna modifica del DB danneggi il programma (almeno non facilmente). Questo è importante perché ogni stato che deve essere aggiunto deve essere prima codificato e non semplicemente aggiunto al DB.

Dovresti comunque avere quei valori di stato scritti nel DB con le loro descrizioni corrette nel caso in cui sia necessario estrarre un rapporto, ad esempio.

Di solito ho un piccolo frammento di codice che si collegherà al DB e verificherà che gli stati elencati in una tabella specifica abbiano tutti gli stessi valori ID / nome che ho codificato in memoria. Se non corrispondono, interromperò l'esecuzione del software.

A seconda delle tue esigenze potresti voler implementare comportamenti leggermente diversi ma nel complesso è una buona idea avere quegli stati codificati in ogni caso.


2

Abbiamo problemi simili sul mio progetto (codice legacy, evviva!) Il problema principale è che "le tabelle enum non cambiano mai" fino a quando non lo fanno e il codice si rompe. Ho due strategie per mitigare che sto lentamente migrando verso.

Innanzitutto, e meglio, è eliminare i riferimenti diretti a questi valori ogni volta che è possibile. Chiedi sempre "perché devo usare direttamente il valore enum?" In molti casi, questo è un segno che il codice ha troppe ipotesi codificate o che sta tentando di manipolare troppo i dati. Verifica se non è possibile stabilire relazioni migliori nel database o un codice più flessibile per gestire ciò che viene manipolato.

Quando non funziona, vado al piano B: generazione del codice. Poiché le tabelle cambiano di rado e pubblichiamo regolarmente nuove build, un generatore di codice può leggere le tabelle enum e scrivere il codice enum. Questa libreria generata dinamicamente viene quindi utilizzata nel progetto. Se il DB cambia, la build successiva non verrà compilata, il che è molto meglio che ottenere misteriosi errori di runtime.


Come elimineresti i riferimenti a un enum? Ad esempio, in questo caso si sta ordinando o cercando uno stato. Avere qualche valore magico nel DB non mi sta bene. Ecco a cosa servono le tabelle di ricerca.
nportelli,

In passato ho fatto il contrario. Ogni volta che si verifica una modifica del codice in Enum, all'avvio dell'applicazione, sincronizza tali valori con il database. Qui il codice è la fonte della verità. Il database ne è una rappresentazione. In genere ignoro i valori nel DB che il codice non può comprendere ma in questo modo ottengo un meccanismo per ripulire automaticamente il DB, se necessario.
Anshul,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.