Enum o tabella di riferimento quando si tratta di mappe

Question

Enum o tabella di riferimento quando si tratta di mappe

#1 da (1 voti)

2

Sto memorizzando informazioni sui widget nel mio database e ogni widget ha una funzione di trasformazione (non univoca) ad esso associata. Il mio problema è come associare i widget alla loro funzione di trasformazione.

Il mio primo istinto era di usare un enum per la funzione di trasformazione. Sto usando sqlalchemy per il mio database ORM, che include un tipo enum questo rende davvero facile usare una colonna di enum. Si prende cura della convalida e posso semplicemente avere un enum nel mio codice per le possibili funzioni di trasformazione, una colonna enum su Widget e quindi una mappa nel mio codice dai valori enum alle funzioni effettive.

Poi ho letto perché le enumerazioni sono malvagie . È piuttosto convincente, ma se uso una tabella di riferimento, non posso usare un oggetto enum python, e la mia mappa dovrà essere da stringhe a funzioni - il che significa che se faccio un refuso potrebbe accadere che sto mappando da una trasformazione che non esiste nel database, che non è buona, e non ho modo di sapere che la mia mappa è esaustiva e corretta.

Qual è il modo migliore per farlo?

database python database-design enum

posta Plasma 09.02.2018 - 03:07

fonte

1 risposta

Leggi altre domande sui tag database python database-design enum

Gestione efficiente delle dipendenze tra i componenti API REST Due possibili metodi di aggiornamento per la stessa risorsa

score 1 · Accepted Answer

Non c'è niente di sbagliato nell'avere una colonna enum nel tuo database o usando le enumerazioni nel tuo programma. Ma non usa entrambi!

Il punto di enumerazione è limitare le possibilità e quindi semplificare la gestione e / o la convalida, ma se le utilizzi in più punti, dovrai mantenere sia il database sia il programma aggiornati.

Significa anche che non è possibile aggiornare un programma su un database senza aver prima aggiornato il database se si aggiunge un nuovo valore possibile. E con questa logica, non è nemmeno possibile downgrade di un programma a una versione precedente o si rischia che esploda quando tenta di caricare un valore dal database che non è considerato dal programma. Ci sono modi per aggirare questo (a prova di futuro), ma non è ancora l'ideale.

Approccio al database

Se si desidera utilizzare il database per i valori enum, si dovrebbe andare al 100%. Ciò significa che qualsiasi informazione relativa all'enum che influirebbe sul comportamento nel tuo programma dovrebbe essere direttamente legata al campo enum nel tuo database. Se necessario, creare una tabella separata con solo valori enum e le sue proprietà a cui fare riferimento dalle altre tabelle. Il programma non dovrebbe quindi mai veramente bisogno di leggere il valore enum per determinare il comportamento. Puoi usarlo per descrizioni o per fare distinzione tra altri record con tipi diversi, ma mai per determinare il comportamento. Questa informazione dovrebbe provenire direttamente dal database.

Approccio al programma

Se si abbandona una colonna del database in cambio di mantenerla nel programma, significa che il programma determina il comportamento, non il database. Il database può ancora avere una colonna, ma dovrebbe essere strettamente un campo VARCHAR. Il tuo programma legge il valore e lo associa direttamente con un tipo enum nel tuo programma e il tuo programma cambia comportamento in base a quel valore enum. Questo ti dà una maggiore flessibilità nel tuo programma e negli aggiornamenti del tuo database. Anche se il tuo programma è in teoria l'unica cosa che scrive questa tabella, manterrei comunque un piano di backup per quando viene utilizzato un valore di tipo che non esiste.