Buona pratica: memorizzazione di variabili e nomi di classi nel database per la chiamata diretta

Questo non ha nulla a che fare con le basi di dati in particolare. Una base di dati è semplicemente un dispositivo per preservare le risorse del tuo programma attraverso invocazioni diverse in modo economico e affidabile. La domanda è: è ragionevole trattare i nomi piuttosto che i contenuti degli attributi degli oggetti, delle classi, ecc. Come risorse nel programma o no?

Se lo è, salvarli e ripristinarli da una base dati è la cosa ovvia da fare quando hai bisogno di persistenza. Se non lo è, allora ci possono essere problemi evidenti con la pratica, ma quelli non sono legati alla persistenza, sarebbero altrettanto gravi se applicati all'architettura della tua applicazione in primo luogo.

(Sto esagerando leggermente qui. Il salvataggio dei dati nell'archiviazione persistente introduce inevitabilmente il problema dei dati legacy che devono essere gestiti dalle nuove versioni del codice, cioè da un codice che non è lo stesso codice che li ha creati Gli schemi di base dei dati sono notoriamente longevi e spesso non sotto il controllo totale, perché devono essere condivisi con altre applicazioni della tua azienda, pertanto, la memorizzazione dei dati tende ad amplificare i problemi architetturali del tuo codice. il punto principale è che la riflessione può o non può essere appropriata, ma non perché causa strane tabelle o elementi dello schema.)

Per prima cosa voglio essere sicuro. Stai memorizzando nomi e classi, ma non codice grezzo, giusto?

Il problema con il codice nel database è che i database non hanno un set di strumenti ben sviluppato per commit / rollback / release / branching / etc come quello che abbiamo con i file. Inoltre mantenere il codice + database in sincrono è una fonte eterna di potenziali problemi. Il 90% delle volte non ci sono problemi, ma ciò rappresenta una fonte del 10% di problemi completamente inutili.

Avere nomi di classi e funzioni nel database è molto flessibile. Il problema è che quindi non si può mai presumere che non si possa fare riferimento a quel database. Il che significa che ogni potenziale refactoring è sempre verboten.

Invece quello che vorrei raccomandare è che tu memorizzi un semplicissimo "livello di traduzione" (che per lo più non fa alcuna traduzione) che non fa altro che sedersi nel tuo codice e mappare dai nomi di classi / funzioni nel tuo codice a quelli corrispondenti nel Banca dati. Ciò non aggiunge alcuna funzionalità immediata tranne per servire da documentazione su quali tipi di informazioni possono essere memorizzate nel database e (altrettanto importante) cosa non lo è. Questo serve come documentazione interna della tua API pubblica che consentirà il refactoring / cleanup in seguito.

In breve, ti permette di superare il test di grep: link

Microsoft memorizza i metadati relativi agli oggetti di SQL Server in un database. Tuttavia, questo meta-dati non è inteso per l'uso di nessuno, tranne un amministratore di database che dovrebbe essere esperto abbastanza da non scherzare direttamente con esso. Quindi, sebbene possa esistere un caso valido per l'archiviazione di tali dati in un database per l'utilizzo del sistema, il caso di consentire a un utente tipico di accedervi e la possibilità di modificarlo senza capire cosa ciò significhi è molto più rischioso. È il peggiore di tutti i mondi se i tuoi utenti non sono tipici amministratori di sys di livello esperto o DBA o sviluppatori stessi. Inoltre, il codice dovrebbe essere nel controllo del codice sorgente e averlo lì e nel database significa che non sarà sincronizzato. E l'intera idea di un certo tipo di FK dinamica colpisce l'orrore nella mia mente, non importa come sia implementata in quanto è una ricetta per i problemi di integrità dei dati.