Quali sono gli argomenti a favore o per mettere la logica dell'applicazione nel livello del database? [chiuso]

La maggior parte degli sviluppatori di software desidera mantenere la logica dell'applicazione nel livello dell'applicazione e probabilmente ci sembra naturale mantenerla qui. Gli sviluppatori di database sembrano voler mettere la logica dell'applicazione nel livello del database, come trigger e procedure memorizzate.

Personalmente preferirei mantenere il più possibile il livello applicazione per rendere più semplice il debug e mantenere separate le responsabilità dei livelli.

Cosa ne pensi e cosa dovrebbe o non dovrebbe essere ok implementare a livello di database?

Modifica Questa domanda è anche trattata su dba.se , dal punto di vista dei DBA. Poiché programmers.se & dba.se hanno un pubblico e un orientamento diversi, i futuri lettori potrebbero voler rivedere entrambi i set di risposte prima di decidere quale funziona meglio per loro.

Dalla parte superiore della mia testa, i vantaggi di mettere la logica nel livello dell'applicazione.

1. Testabilità . Questo dovrebbe essere un motivo abbastanza buono da solo in realtà.
2. Migliore struttura del codice . È molto difficile seguire la corretta architettura OO con SQL. Questo di solito semplifica anche la manutenzione del codice.
3. Più facile da codificare . A causa di tutte le diverse funzionalità linguistiche disponibili in qualunque lingua tu stia usando, di solito è più facile programmare nel livello applicazione.
4. Riutilizzo del codice . Condividere il codice con le librerie è molto più semplice che condividere il codice nel database.

Sebbene sia possibile utilizzare il controllo versione con procedure memorizzate (ad esempio gli strumenti del database Redgate si integrano con TFS), non è sempre così semplice come con il codice dell'applicazione.

La mia posizione predefinita è che la logica dovrebbe essere tenuta fuori dal livello del database, tuttavia, ci sono momenti in cui sarebbe più efficiente implementare la logica nel database. In tal caso, è necessario assicurarsi di poter tenere traccia delle modifiche a questo codice.

In una società in cui ho lavorato c'era molta burocrazia coinvolta nel rilasciare il codice in produzione e coinvolgere un DBA per un rilascio di codice era sempre un incubo. Mettiamo sempre la logica nel livello dell'applicazione per eliminare la necessità di gestire i DBA con i quali è difficile lavorare. È una ragione totalmente sbagliata, ma derivata per necessità.

Inserire la logica dell'applicazione nel DB mi sembra una cattiva idea. OTOH che inserisce nel DB una logica che fa specificamente parte del mantenimento dello stato del DB (ad es. Trigger / sprocs per aggiornare tabelle non normalizzate) è una proposta molto diversa.

In alternativa, questo può essere affermato come: ci sono buoni argomenti per mettere la logica necessaria per sottrarre il modo in cui il database funziona davvero da come lo si desidera guardare nel database.

Avendo letto entrambe le domande, penso che potremmo aver perso tutti un punto critico. La risposta corretta può dipendere dal tipo di software che stai sviluppando. Il gruppo DBA tende in gran parte a lavorare su sistemi software Enterprise business-critical e le loro risposte tendono a riflettere ciò che è necessario in quel mondo. C'è un'enorme differenza in ciò che è necessario per questi tipi di applicazioni rispetto a ciò che è necessario per la prossima applicazione "Facebook". Non è un grosso problema se perdi un paio di messaggi a muro, è se perdi un paio di ordini o altre transazioni finanziarie.

Le persone che lavorano nel mondo COTS (commerciale off-the Shelf) tendono ad avere agnostico nel database per motivi di vendita e vogliono che tutto nel codice rispettato renda più difficile il reverse engineering e la sostituzione del loro prodotto con uno di produzione propria. Le applicazioni Enterprise sviluppate e gestite internamente non dovranno quasi mai cambiare i back-end del database se non per l'aggiornamento.

Le applicazioni aziendali sono anche quelle che tendono ad avere input da molti luoghi con il database come unica caratteristica comune. Il sistema in cui lavoro ha centinaia di diverse applicazioni che vi accedono, nonché centinaia di importazioni di dati dei clienti, esportazioni di dati verso i clienti e verso i data warehouse e utilizza sistemi di reportistica multipla. Il codice che funziona bene quando si aggiunge un record non riesce quando devo importare 20.000.000. Siamo stati costretti a utilizzare il livello applicazione una volta perché era lì che era la logica e dovevamo interrompere il processo 18 ore dopo incompiuto. La logica che deve essere applicata a tutti i record di dati in una tabella deve trovarsi nel database quando non è possibile disporre di un livello dati utilizzato da tutti.

Al contrario, quando una sola applicazione consumerà i dati e questi non sono la linfa vitale della tua azienda o sono effimeri, le regole sono diverse e mettere tutta la logica nell'applicazione ha più senso.

Lunghetta. vedi Riepilogo in fondo.

RDBMS

Un RDBMS sta per sistema di gestione di database relazionali. È un sistema per gestire una base di dati relazionale. I dati sono memorizzati lì. I dati. Non dice logica commerciale.

Processo di business

Cosa significa veramente la logica aziendale? Per me, è una descrizione dei processi aziendali in termini logici.

I processi sono quelle attività commerciali che si svolgono regolarmente, abbastanza da non essere più ad hoc. Questi sono diversi per ogni azienda.

Consentitemi di mettere il mio cappello aziendale e spiegare cosa significa affari qui. Per alcuni, questo può essere una sorpresa.

Attività commerciale

Il business è la somma delle attività svolte per raggiungere la creazione di valore, e più specificamente valore che può essere scambiato. Ciò potrebbe significare preparare mietitrebbie, sandwich al tonno o fornire servizi bancari. Nella maggior parte dei paesi del mondo, anche nei sistemi non capitalistici, alle persone piace ottenere il massimo valore per i loro soldi, e quindi c'è concorrenza tra i diversi fornitori di questi beni e servizi di valore. La concorrenza dipende generalmente dal prezzo, dalla qualità e dalla disponibilità.

Deviazione rapida: hai bisogno di 40 milioni di rivetti in 2 giorni, non ordinerai da un ragazzo su Internet con un account paypal, non importa quanto sia più economico il suo prezzo rispetto a quello del tuo normale venditore.

Conoscenza del processo

Come puoi immaginare, i processi coinvolti nel rendere questo "valore" vivono principalmente nei dirigenti. Alcuni di questi vengono messi su carta e utilizzati come politiche e procedure aziendali. Alcuni di questi vivono nei capi di consulenti aziendali. Molto di questo vive nella testa delle persone che gestiscono le divisioni, i dipartimenti, i team e quelli che gestiscono le macchine, i registratori di cassa, i forni, i camion. Un piccolo sottoinsieme di questi riduce i requisiti aziendali per il software, e un sottoinsieme ancora più piccolo di questo è accurato quando viene implementato nei sistemi informatici.

Alla fine, la logica di business che vedi nel codice non è quella che gestisce un'azienda, è quella che esegue l'applicazione per l'azienda. I cervelli reali all'interno delle persone reali detengono i processi aziendali reali e non hanno alcun problema a capire che il processo nel loro cervello è più accurato del processo nel computer. A parte questo, probabilmente non potresti gestire l'attività se tutto ciò che avessi fossero le politiche e le procedure della maggior parte delle aziende. Molto spesso questi sono grossolanamente inaccurati, nonostante gli sforzi erculei.

Quindi, alla fine, è la logica dell'applicazione che è codificata nel software. E la gente vuole metterlo nel database, perché i venditori del sistema di gestione del database hanno fatto affermazioni grandiose.

Logica dell'applicazione

Dico di no Dico che la logica dell'applicazione rimane all'interno dell'applicazione. I dati vengono archiviati nel database, in un modo molto normalizzato, quindi vengono trasferiti in ETL al datawarehouse per la creazione di report, il drill e il rollup, il pivot e il cubing.

Dati

Dico anche che i dati sopravvivono all'applicazione, quindi lo sforzo di normalizzazione dei dati non dovrebbe essere specifico per l'applicazione, e nemmeno specifico per il business, ma piuttosto dovrebbe essere business-general. Memorizzi i codici di stato? Dovresti usare INCITS 38: 2009 (http://www.census.gov/geo/www/ansi/statetables.html) perché è portatile in tutte le aziende. Ciò semplifica inoltre la manipolazione dei dati da parte di più applicazioni.

NoSQL?

Se tratti il ​​database come parte del codice dell'applicazione, dal layout delle tabelle ai trigger, alle procedure memorizzate e ai formati dei dati, stai essenzialmente utilizzando il database aziendale come un BerkleyDB glorificato, che è una struttura di file flat glorificata, che è in realtà solo liste persistenti. Questo è essenzialmente ciò che sta facendo NoSQL: tornare alle origini, ma farlo in modo multiprocesso, persistente, tollerante ai guasti.

Codice attuale

No, è necessario trattare la base di dati come un archivio comune di dati per più applicazioni, sia attuali che future. Ora veniamo al nocciolo della mia discussione. I processi aziendali cambiano con i capricci del mercato, della politica e della moda. Molto spesso cambiano più velocemente di quanto i programmatori possano gestire con linguaggi di livello informatico (Java, C #, C ++ ecc.) E finiscono per essere scritti in VBA in fogli di calcolo Excel nel reparto contabilità o marketing. (E solo se non può essere espresso in fantasiosi vlookup ...)

Degrado del database

I dati non cambiano molto se sono ben organizzati. La logica aziendale cambia molto rapidamente. Inserendo la logica di business nel database, si rende il database meno prezioso, perché diventerà obsoleto e impreciso prima.

Sommario

I dati devono sopravvivere all'applicazione perché i processi aziendali vivono nell'applicazione e i processi aziendali cambiano molto più spesso. L'inclusione della logica di business nel database è dannosa per la sua longevità e il valore complessivo.

Avvertimento

Ho fatto la mia parte di dba-ing e ho letto le risposte su dba.se ma in tutta onestà di cosa stanno parlando sono problemi di integrità dei dati e problemi di prestazioni. Concordo pienamente sul fatto che le persone che toccano i dati aziendali debbano sapere cosa stanno facendo, siano essi dba o programmatori o analisti senior SAS con accesso in lettura / scrittura.

Ho anche notato che raccomandano ai programmatori di conoscere SQL. Sono d'accordo. È un linguaggio di programmazione per computer, quindi non vedo perché i programmatori di computer non vorrebbero conoscerlo.

Più tardi, dopo averci pensato

Penso che la via di mezzo sia creare un'API e far sì che l'API gestisca il flusso di dati avanti e indietro. Se non riesci a consentire alle app di connettersi direttamente ai tavoli, almeno puoi rendere il meccanismo di accesso in lingue moderne.

A rischio di sembrare drammatico, sono sinceramente inorridito dall'idea della logica dell'applicazione nel database. Molte risposte qui si sono concentrate sui vantaggi dello sviluppo del software, quindi per brevità, mi concentrerò sui vantaggi offerti dalla divisione delle responsabilità.

I database forniscono un mezzo efficiente per archiviare e accedere alle informazioni, riducendo al minimo i dati ridondanti e producendo relazioni logiche nei dati. Mentre la logica del database potrebbe essere in grado di implementare la logica di business a livello di produzione, la mia opinione personale è che il database dovrebbe essere il più agnostico possibile per garantire che i dati possano essere sfruttati efficacemente da più applicazioni mentre giocano ai rispettivi punti di forza del database motore rispetto ai punti di forza del linguaggio di implementazione dell'applicazione.

Un utente nello scambio di stack DBA ha dichiarato questo ...

Voglio tutta la logica che deve essere applicata a tutti gli utenti e a tutte le applicazioni nel database. Questo è l'unico posto sano per dirlo.

L'ultima Fortune 500 a cui ho lavorato ha avuto applicazioni scritte in almeno 25 lingue colpendo il loro database OLTP. Alcuni di questi programmi passarono alla produzione negli anni '70.

... seguito dalla sua convinzione che ciò sia indicativo di una violazione del principio DRY.

Piuttosto che essere una ripetizione della logica aziendale, penso che questo sia più probabilmente un perfetto esempio della flessibilità fornita da una distinta divisione delle responsabilità tra il livello aziendale e il livello dati.

Il loro database OLTB ha fornito dati in modo affidabile ed efficiente a oltre 25 applicazioni per decenni! È stupefacente! (Ben fatto!)

Posso solo supporre che i dati siano abbastanza agnostici da fornire contenuti per un numero di applicazioni distinte. Qualcosa che sarebbe in gran parte impossibile se quegli sviluppatori tentassero di hackerare qualcosa insieme usando la logica del database.

Come indicato da altre risposte, ci sono molte altre ragioni per non implementare un programma nel database. Sono sicuro che funzionerebbe, ma il risultato più probabile sarebbe decenni di rimpianti, piuttosto che decenni di stabilità.

Le applicazioni agnostiche del database richiedono tutta la logica dai database. È molto difficile creare e mantenere il codice per molti provider di database diversi.

Un buon sviluppo creerà un buon equilibrio tra la necessità di integrità e velocità del database inserendo parte della logica nel database e la maggior parte dell'applicazione.

La stessa query verrà utilizzata più e più volte in molte applicazioni, quindi forse appartiene a una procedura memorizzata.

Accertarsi che i campi di pulizia siano impostati quando una riga viene inserita e aggiornata è una responsabilità DBA. Verrà utilizzato un trigger.

D'altra parte, se ho una logica aziendale, deve essere nell'applicazione. Quando possibile, dovrebbe effettuare chiamate a stored procedure che restituiranno il set di record filtrato desiderato con l'esatta quantità di campi necessari. Non di più, non di meno.

È una questione di comunicazione tra i team e una questione di riconoscimento dei pro e dei contro per ogni possibilità.

La mia opinione è: non rendere la logica dell'applicazione troppo profonda nel DB.

Alcuni sistemi di trading forniscono un modo per estendere la funzionalità esistente con script, fondamentalmente inseriti nel database. La mia esperienza con questo è piuttosto negativa, almeno in un ambiente multiutente.

Inseriresti la logica in un database, perché vorresti poterlo modificare facilmente.

• Come faresti il ​​controllo della versione?
  • Qual è la cronologia del codice? Quali sono stati i cambiamenti? Da chi?
  • Come è possibile gestire le modifiche sugli stessi frammenti di codice?
• Come identificheresti e garantiresti uno stato di codice coerente?

Potresti rintracciarlo in un VCS basato su file aggiuntivo, ma allora qual è il vantaggio del database?

La maggior parte delle applicazioni deve avere un modo per fornire l'integrazione. Idealmente, si avrebbe un'API completa, un servizio Web o almeno rendere disponibili alcuni oggetti di database contenenti la logica aziendale. Non tutti sono in una posizione di tempo / risorse per costruire un'API, quindi devi scendere a compromessi.