Il modo migliore per fare riferimento a dati di database statici nel codice?

Molte applicazioni includono "dati statici": dati che non cambiano realmente durante la vita dell'applicazione. Ad esempio, potresti avere un elenco di aree di vendita che probabilmente sarà un elenco fisso per il prossimo futuro.

Non è raro trovare questi dati statici in una tabella di database (spesso perché si desidera fare riferimento ad essi nelle chiavi esterne di altre tabelle). Una semplice tabella di esempio avrà un ID da utilizzare come chiave primaria e una Descrizione. Ad esempio, la tabella SalesArea avrà (almeno) una colonna SalesAreaId e una colonna SalesAreaDescription.

Ora, nel codice potresti non voler trattare ogni riga della tabella allo stesso modo. Ad esempio, potresti voler impostare un'area di vendita predefinita su alcune schermate, fornire cifre diverse per alcune aree o limitare ciò che gli utenti possono fare in altre aree.

Qual è il modo migliore per fare riferimento a questi dati statici nel codice? Perché?

1. Inserisci nel codice le descrizioni nel tuo codice. Usalo per cercare SalesAreaId dal database quando ne hai bisogno.
2. Inserisci nel codice gli ID nel tuo codice. Usalo per cercare SalesAreaDescription quando ne hai bisogno.
3. Aggiungi una colonna alla tabella per ogni scopo, ad esempio una colonna "IsDefaultOnProductLaunchScreen" e così via (potrebbero essercene molte).
4. Qualcos'altro.

Ci sono altre considerazioni speciali che dovrei fare quando ho a che fare con dati di database statici? Ad esempio, dare a queste tabelle un nome speciale?

Che ne dici di caricarli in una cache (di solito implementata come una tabella hash) all'avvio dell'applicazione? Se lo fai, non devi nemmeno interrogare il database (beh, non più di una volta).

Vorrei anche suggerire di evitare qualsiasi codifica. Aggiungi indicatori predefiniti (inizialmente nella tabella DB e anche nella struttura della cache) per le schermate che richiedono impostazioni predefinite. Per eseguire ricerche su non defauilt, prova a memorizzare le chiavi che verranno cercate in un file di configurazione o proprietà, se possibile.

Un'alternativa al DB o alla codifica hardware consiste nell'utilizzare un file di configurazione letto al momento dell'avvio. È quindi possibile archiviare questi dati in una struttura di sola lettura all'interno del codice.

Nel raro (ma non impossibile) caso in cui modifichi questi dati dovrai riavviare l'app. Se ciò non è possibile, è possibile scrivere un gestore di configurazione più complesso che controlla le modifiche nel file di configurazione ogni volta che si accede ai dati, questo è in realtà abbastanza efficiente poiché è necessario solo controllare un timestamp sul file e quindi invalidare tutti i dati se il file è aggiornato.

Se i dati si riferiscono a dati esistenti nel tuo DB, è probabilmente altrettanto efficace aggiungerli al DB quanto aggiungerli al codice. In caso contrario, di solito sono tentato di "prendere quel proiettile una volta" e inserirlo nel codice fino alla prima modifica.

Spesso ciò che riteniamo statico risulta non esserlo, e quando ciò accade, non si deve attendere il rilascio di un codice per passare una modifica. Non appena ciò accade una volta, inserirlo nel database e scrivere una pagina dell'amministratore per eseguire ulteriori aggiornamenti.

Per fare un esempio, se nel DB sono già presenti Aree di vendita, aggiungere una descrizione lì, non creare una tabella hash per mettere in relazione i dati del database con elenchi codificati. Ma se non costruisci una tabella hash delle aree di vendita con tutti i mezzi, ma sii pronto, la prima volta che qualcuno modifica una descrizione o aggiunge una nuova area di vendita, spostala nel DB.

Perché non solo codificare tutto? Il problema principale che ho sempre avuto è il riferimento ai valori statici dal DB nel codice dell'applicazione. Una cosa è se stai semplicemente creando un elenco a discesa o qualcosa fuori dai valori statici, ma cosa succede se una logica dell'applicazione dipende dai valori dal DB?

In una semplice app al momento ho un elenco di stati di modifica per contenuti: bozza, pubblicato, archiviato.

Gli elementi di contenuto devono essere trattati in modo diverso a seconda dello stato in cui si trovano. Se dovessi conservare questi dati di stato nel DB, con i valori 1, 2, 3, rispettivamente, come farei per verificare se qualcosa è in Bozza stato?

if (content.State == 1)
o
if (content.State == "Draft")?

Ho appena codificato i valori!
Stessa cosa se usi una tabella cache / hash: devi ancora usare un valore scritto nel tuo codice come chiave per cercare i tuoi dati.

Quali sono gli svantaggi dell'approccio hard-coding?

Simile a ciò che ha detto FrustratedWithFormsDesigner, questo viene in genere eseguito con una cache, in quanto significa che devi sempre caricare i dati statici una sola volta, ma segue il modello OAOO, il che significa che non stiamo definendo i dati in due punti (database e in il tuo codice).

So che NHibernate ORM offre questa funzionalità attraverso una cache di 2 ° livello . Puoi dire che memorizza nella cache i dati da una determinata tabella e dire che è di sola lettura. Verrà caricato la prima volta che è necessario e dopo non accederà più al database, anche se si accede ai dati da più sessioni.

Questa è l'ottimizzazione prematura nel suo peggio.

In primo luogo, qualsiasi DBMS moderno recupererà i dati da piccole tabelle alla velocità della luce e tutti hanno algoritmi di memorizzazione nella cache che vanno dal buono al superbo (più si paga per il DBMS, migliore è la cache!). Quindi stai ottimizzando qualcosa che consuma risorse minime.

In secondo luogo, hai pochissima esperienza con le applicazioni del mondo reale se immagini che qualcosa come "un'area di vendita" siano dati statici. Questi possono cambiare con ogni cambio di Direttore Marketing o CEO. Quindi stai andando in un mondo di dolore due anni dopo.

Ci sono solo due modi per andare qui: -

Archiviarlo in un database e accedere ai dati con sql "normale".

Archiviarlo in un file di configurazione XML di fantasia (eventualmente accessibile tramite REST o SOAP) che può essere facilmente modificato ogni volta che si verifica un "cambio strategico di politica".

Dipende da cosa stai facendo con i dati. Se è un elenco di qualcosa, generalmente lo inserirò in un array. Se l'elenco deve crescere in un'altra versione, è facile semplicemente aggiungere al database e modificare il codice per gestire i dati aggiuntivi nell'array (che potrebbe non essere nemmeno necessario a seconda del codice, ad esempio elencando i dati con un per loop usando il limite superiore dell'array). Se si tratta di un elenco di impostazioni, in genere codificherò quelle in quanto di solito non ce ne sono molte ed è più facile e veloce rispetto all'utilizzo di un'istruzione SQL. Se si tratta di un'impostazione che l'utente può modificare e voglio salvare la selezione per i successivi lanci, creerò una tabella da utilizzare come registro e trascinerò le singole voci nelle variabili secondo necessità.

So che questa risposta è stata accettata, ma volevo condividere come l'abbiamo fatto nel mio ultimo negozio di sviluppo web, dove abbiamo cercato di ridurre il più possibile l'I / O del database.

Abbiamo utilizzato i file di inclusione lato server per il maggior numero possibile di strutture di dati di tipo ricerca. Principalmente questo era per la navigazione del sito (per includere la subnavigazione) ma l'abbiamo anche usato per il maggior numero possibile di menu a discesa e caselle di controllo (Stati, Paesi, Categorie).

Inizialmente, abbiamo estratto tutti questi dati dal database. Dal momento che abbiamo fornito al cliente un widget di amministrazione, questi potrebbero cambiare questi dati a piacimento e non ci siamo mai impantanati con piccole modifiche al nichel-centesimo. Il più delle volte questi dati non sono quasi mai cambiati ma, occasionalmente, sarebbero cambiati.

Siamo sempre stati alla ricerca di tempi di caricamento più rapidi. Quindi abbiamo deciso di implementare quanti più file di testo lato server statico possibile. Lo abbiamo fatto a lato del widget di amministrazione. Ogni volta che veniva aggiornata una tabella del database, rigeneravamo il corrispondente file di testo statico. Questo ci ha dato un ambiente molto flessibile e veloce.

La mia soluzione a questo, che potrebbe non funzionare in tutte le situazioni, è quella di associare i dati del database statico a un hard-coded enum. Poiché il problema deriva dall'avere dati dinamici (database) associati alla logica statica (codice), rendere esplicito (e sciolto) questo legame avendo una tabella di database che si associa al enum. Ex:

LooseDBCodeBinding (database table)
   ID : Int32 (key)
   Name : String
   HardCodedTypeID : Int32

// in code:
public enum LooseDBCodeBinding
{
   TYPE_1 = 1,
   TYPE_2 = 2,
   TYPE_3 = 3 // etc...
}

Quindi scrivere un'interfaccia utente che ti consenta di visualizzare facilmente l'elenco dei LooseDBCodeBindingrecord e di mapparli su LooseDBCodeBinding enumvalori (incluso il supporto di associazioni "non funzionanti"). È quindi possibile programmare intorno a enum, e progettare il database attorno alla chiave della tabella, ed è solo questa tabella che ha conoscenza di entrambi i contesti.