Il modo migliore per fare riferimento ai dati del database statico nel codice?

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

Suggerirei anche di evitare di codificare qualsiasi cosa. Aggiungi indicatori predefiniti (inizialmente nella tabella DB e anche nella struttura della cache) per le schermate che necessitano di valori predefiniti. Se fai ricerche su non-defauilts, prova a memorizzare le chiavi che verranno cercate in un file di configurazione o proprietà, se possibile.

Un'alternativa al DB o hard coding è quella di utilizzare un file di configurazione letto in fase di avvio. Potresti quindi memorizzare questi dati in una struttura di sola lettura all'interno del tuo 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, in realtà è abbastanza efficiente in quanto è sufficiente controllare un timestamp sul file e quindi invalidare tutti i dati se il file è aggiornato.

Se i dati si riferiscono a dati esistenti nel DB, è probabilmente altrettanto efficiente aggiungerlo al DB poiché è necessario aggiungerlo al codice. In caso contrario, di solito sono tentato di "prendere quel proiettile una volta" e di inserirlo nel codice fino alla prima modifica.

Spesso ciò che pensiamo sarà statico risulta non essere, e quando ciò accadrà, non vorrete aspettare un rilascio di codice per far passare una modifica. Non appena ciò accade una volta, inseriscilo nel database e scrivi una pagina amministratore per ulteriori aggiornamenti.

Per fare il tuo esempio, se hai già Aree di vendita nel DB, aggiungi una descrizione, non creare una tabella hash per correlare i dati del database con gli elenchi hard-coded. Ma se non si crea 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 tutto il codice? Il problema principale che ho sempre avuto è fare riferimento ai valori statici del DB nel codice dell'applicazione. Una cosa è se si sta semplicemente creando un elenco a discesa o qualcosa fuori dai valori statici, ma cosa succederebbe se una qualche logica applicativa dipendesse dai valori del DB?

In una semplice app al momento ho un elenco di stati di modifica per parti di contenuti: Bozza, Pubblicato, Archiviato.

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

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 certo valore scritto nel tuo codice come chiave per cercare i tuoi dati.

Quali sono gli svantaggi dell'approccio hard-coding?

Simile a quello che ha detto FrustratedWithFormsDesigner, questo in genere è fatto con una cache, poiché significa che è necessario caricare i dati statici solo una volta, ma segue il modello OAOO, il che significa che non stiamo definendo i dati in due punti ( database e nel tuo codice).

So che l'NHM di NHibernate offre questa funzionalità attraverso un cache di secondo livello . Puoi dirlo per memorizzare i dati da una certa tabella e dire che è di sola lettura. Verrà caricato la prima volta che sarà necessario, e non colpirà più il database dopo questo, anche se accederai ai dati da più sessioni.

Si tratta di un'ottimizzazione prematura peggiore.

In primo luogo qualsiasi DBMS moderno recupererà i dati da piccole tabelle alla velocità della luce e tutti hanno algoritmi di caching che vanno da buoni a superbi (più hai pagato per il DBMS migliore è il caching!). Quindi stai ottimizzando qualcosa che consuma risorse minime.

In secondo luogo, hai pochissima esperienza di applicazioni aziendali del mondo reale se immagini che qualcosa come una "zona di vendita" sono dati statici. Questi sono suscettibili di cambiare ad ogni cambio di direttore marketing o CEO. Quindi ti stai dirigendo verso un mondo di dolore a due anni di distanza.

Ci sono solo due modi per andare qui: -

Archivialo in un database e accedi ai dati con "normale" sql.

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

Dipende da cosa stai facendo con i dati. Se è una lista di qualcosa, di solito la metto in un array. Se l'elenco deve crescere in un'altra versione, è facile aggiungere semplicemente al database e modificare il codice per gestire i dati aggiuntivi nell'array (che potrebbero non essere nemmeno necessari 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 eseguirò il codice di quelli che di solito non sono molti ed è più semplice e veloce rispetto all'utilizzo di un'istruzione SQL. Se è un'impostazione che l'utente può modificare e voglio salvare la selezione per i lanci successivi creerò una tabella da utilizzare come registro e semplicemente inserirò le singole voci in variabili, se necessario.

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

Abbiamo usato i file di inclusione lato server per il numero di strutture di dati di tipo "look up" che potevamo. Principalmente questo era per la navigazione del sito (per includere la sottonavigazione) ma lo usavamo anche per il maggior numero di caselle a discesa e checkbox possibili (Stati, Paesi, Categorie).

Originariamente, abbiamo preso tutti questi dati dal database. Dato che abbiamo dato al cliente un widget di amministrazione, potevano cambiare questi dati a piacimento e non ci siamo mai impantanati con piccole modifiche al nichel-dime. Il più delle volte questi dati non sono quasi mai cambiati ma occasionalmente cambierebbe.

Abbiamo sempre cercato tempi di caricamento più rapidi. Quindi abbiamo deciso di implementare il maggior numero possibile di file di testo sul lato server statico. Lo abbiamo fatto nel lato del widget di amministrazione. Ogni volta che veniva aggiornata una tabella di database, veniva rigenerato il corrispondente file di testo statico. Questo ci ha dato un ambiente molto flessibile e veloce.

La mia soluzione a questo problema, che potrebbe non funzionare in tutte le situazioni, è quella di associare i dati del database statico a un enum codificato. Dal momento che il problema deriva dall'avere dati dinamici (database) legati alla logica statica (codice), rendere esplicito (e allentato) questo legame avendo una tabella di database che si associa a enum . Es:

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 scrivi un'interfaccia utente che ti consenta di visualizzare facilmente l'elenco dei record LooseDBCodeBinding e associarli a valori di LooseDBCodeBinding enum (incluso il supporto dei collegamenti "non funzionanti"). Puoi quindi programmare attorno a enum e progettare il database attorno alla chiave della tabella, ed è proprio questa una tabella che ha conoscenza di entrambi i contesti.