Voglio davvero un Enum dinamico o qualcos'altro? Meglio il caching? Una Struct?

Question

Voglio davvero un Enum dinamico o qualcos'altro? Meglio il caching? Una Struct?

#1 da (4 voti)
#2 da (2 voti)

4

Questa domanda viene posta su SO e questo sito spesso assomiglia. "Come faccio un enum dinamico?" Le risposte vanno da te non a possibili soluzioni di tempo di compilazione. Ora la mia domanda è: voglio un enum dinamico che viene generato dalle tabelle di ricerca nel DB, o desidero qualcos'altro che sia simile?

Ho una soluzione che utilizza T4 in fase di compilazione per generare enumerazioni dalle tabelle DB, che funziona bene. Ma ora alcune delle tabelle di ricerca hanno una bandiera 'attiva' su di esse. Questo significa che non stanno più cercando tabelle? Se questo è cambiato, voglio in qualche modo rigenerare il mio codice senza doverlo ridistribuire. Queste tabelle non cambieranno spesso.

Attualmente l'app quando vuole popolare un menu a discesa o qualcosa interrogherà il DB. Ma se i valori rimangono per lo più statici, perché andare al DB ogni volta, quindi usare l'enumerazione. Ha anche il vantaggio di liberarsi delle stringhe e dei numeri magici.

Le strutture statiche sarebbero migliori? Qualche tipo di memorizzazione nella cache per le tabelle di ricerca? Qualche consiglio benvenuto.

database web-development enum

posta nportelli 28.01.2013 - 22:14

fonte

2 risposte

Leggi altre domande sui tag database web-development enum

Come funziona l'autenticazione con ASP.NET (utilizzando Live ID e \ o Autenticazione Windows) Livello logico aziendale completamente separato da MVC

score 4 · Answer 1

Non andare al DB ogni volta. Vai al DB all'avvio del processo; carica in dizionari di sola lettura i tuoi dati di ricerca e chiamali bene. Cambia le cose sotto, devi riavviare l'app per riprendere quei dizionari.

In alternativa, guarda il costo effettivo delle risorse per cercare ogni volta i dati, se la tua app non è abbastanza significativa perché ciò possa avere importanza, lascia che sia sempre a cercare i dati via join.

La scadenza della cache è una cosa complessa ma mi vengono in mente due tecniche molto semplici:

Blocca le tabelle di ricerca in modo che vengano aggiornate dall'app e tali aggiornamenti possono segnalare la ripetizione dei dizionari di sola lettura della tabella di lettura, a patto che non sia necessario preoccuparsi delle persone che cambiano le tabelle di ricerca direttamente attraverso studio di gestione o altro.
Utilizzo del broker di messaggi del server SQL attivato sugli aggiornamenti delle tabelle di ricerca per inviare un messaggio alla tua app in esecuzione che segnala di sostituire i dizionari di sola lettura con versioni aggiornate. Questo presumerà che gli aggiornamenti saranno script SQL manuali

In alternativa, usa una cache appropriata come appfabric o memcached per questi dove puoi avere la scadenza appropriata della cache, se necessario. Questo sembra eccessivo per quello che potrebbe essere davvero benissimo dal mio suggerimento iniziale, la maggior parte dei sistemi hanno gli amministratori che disattivano la loro app quando aggiornano il proprio DB direttamente e lo riaccendono solo dopo aver completato gli aggiornamenti del database.

In sommario:

No, non vuoi enumerazioni dinamiche, questo va contro ciò che enum è anche per

Le enumerazioni sono denominate Sts. Ricordalo, cons. Non appena vuoi un gruppo di coppie di valori-chiave, stai iniziando il percorso di hashtable / dictionary / associative-array o qualunque parola tu voglia chiamare, questo è precisamente lo scopo di tali strutture. Non lo scopo delle enumerazioni.

score 2 · Answer 2

Se qualcosa è un enum e se lo sai al momento della compilazione sono 2 problemi separati. Nel caso in cui si conoscono sempre i valori al momento della compilazione (anche se cambia rispetto alle versioni), e sembra comodo averlo come una sorta di oggetto tipizzato esplicitamente nel linguaggio orientato agli oggetti e come una tabella nel DB , quindi penso che il codice che genera l'oggetto dal DB (o qualsiasi cosa che ASCIUGA - generando uno script DB tramite riflessione, generando lo script DB e la generazione di oggetti da qualcos'altro ...) è OK

Se dovresti modellarlo come enumerazione è un problema separato. Le enumerazioni non sono molto flessibili quando cambiano i requisiti, quindi sarei cauto.

Dici anche che non vuoi ridistribuire. Sembra il nemico della chiarezza. Se le modifiche alle "enumerazioni" (o qualsiasi altra cosa risultino) si verificano più spesso delle versioni, allora non si conoscono i valori in fase di compilazione. Quindi dovresti ottenerlo dal DB, con o senza cache in base alle solite considerazioni.