File di configurazione per le regole aziendali a livello di database

Question

File di configurazione per le regole aziendali a livello di database

#1 da (3 voti)

4

Nella mia applicazione, ho un sacco di query SQL con logica aziendale incorporata in esse. Ad esempio, nelle ricerche "nascondo" i risultati che sono di basso livello, meno di -5 "valutazione della community" perché tali risultati contengono spam, imprecisioni, ecc. E sono stati segnalati dalla comunità.

Nella mia query SQL, potrebbe essere:

SELECT
    ...
    ...
WHERE community_rating > -5

Qui inserisco la logica di business direttamente nella query. E se cambiassimo le nostre opinioni in seguito sulla soglia per nascondere i risultati? Al momento ho 4 query che usano questo numero magico, e altre potrebbero venire.

Il mio istinto dice di estrarre questi numeri in un "file di configurazione del database", perché i numeri vengono riutilizzati molto e possono essere modificati, ma sono tentato di dire di no perché aggiunge molta confusione mentre aggiungete altro $ -type variabili come:

SELECT
    ...
    ...
WHERE community_rating > $5

E avrei una serie di valori da passare alla query come:

[..., ..., ..., ..., DB_CONFIG.HIDE_RESULTS_AT_RATING]

Immagino che diventerà ancora più difficile e difficile da capire nel tempo, ma probabilmente è l'inesperienza a parlare.

Si dovrebbe estrarre la logica di business a livello di database in un file di configurazione ?

Modifica : questo è il back-end di un servizio web. Questo non è un parametro che un utente che sta facendo una ricerca può cambiare. In tutte le query, i risultati vengono esclusi a questa soglia e la soglia viene decisa da me. Esistono più funzioni di ricerca, che utilizzano tutte questa soglia.

database configuration-management

posta Chris Cirefice 12.07.2015 - 18:47

fonte

1 risposta

Leggi altre domande sui tag database configuration-management

In MVC, chi è responsabile della gestione degli osservatori? DDD - Duplicazione tra aggregati - dovrei usare una tabella?

score 3 · Accepted Answer

I file di configurazione dovrebbero essere quasi gli ultimi posti in cui inserire regole o parametri aziendali. I file di configurazione dovrebbero in genere essere utilizzati solo per le funzioni amministrative, cose che l'amministratore di DB o l'amministratore IT controllerebbero, certamente non la logica aziendale.

Uno dei motivi principali per cui i file di configurazione per la business logic sono errati è che in genere le regole aziendali non cambiano solo nei valori ma evolvono da semplici a complesse. Possono crescere da una lista di attributi per diventare un albero di politiche e quindi un sacco di codice procedurale verrà aggiunto per elaborarli in script di supporto che diventano mal gestiti.

Un altro aspetto da ricordare è che quando prendi $ 5 - ti aspetti di cambiare mentre il server è in esecuzione? Dipende dalla tua esatta implementazione, ma quanto spesso vuoi continuare a caricare e analizzare i file di configurazione? e se il valore della politica cambia, come si comunica che la politica deve essere ricaricata?

Un posto molto migliore per mantenere i parametri è DB stesso! Puoi avere uno dei CONFIG_TABLE in cui ogni attributo (colonna nella tabella DB) è un parametro specifico. Può essere semplice una tabella o può essere annidata con più tabelle. Puoi avere diversi profili di criteri, che sono solo diverse righe di questa tabella.

Se attraverso qualche altra interfaccia dell'applicazione, i parametri possono anche essere modificati, se necessario, e la prossima query che verrà attivata automaticamente la incorpora.