Logica aziendale: database vs codice [duplicato]

Vedi Quanta logica di business dovrebbe implementare il database? per la discussione precedente.

In generale, tutti vogliono le cose fatte nel livello che controllano. Perché poi lo controllano.

Ogni fornitore di database vuole che le persone inseriscano il maggior numero possibile di logica nel database. Perché questo ti blocca nel database. Il ragionamento è che se più applicazioni utilizzano lo stesso database, riutilizzeranno il codice.

Tuttavia i programmatori sono in netto disaccordo. I database offrono scarse opzioni di programmazione. Distribuire il codice ai database è difficile. I database non dispongono di strumenti di base per il controllo delle revisioni, l'editing interattivo, la distribuzione e il test delle unità. Le procedure memorizzate tendono a implicare un'azione di debug orribile a distanza. È diventato meno comune avere più applicazioni colpire lo stesso database. E se mai dovessi fare qualcosa di scala, il collo di bottiglia più difficile da risolvere è il tuo database.

Il mio pregiudizio è chiaro. Sono un programmatore.

Ma sto programmando da quasi 20 anni, principalmente come programmatore di back-end che è responsabile dei dati. Ho visto l'argomento molte volte per spostare la logica nel database. Ho visto sistemi che lo hanno fatto e sistemi che lo hanno evitato. Ho dovuto migrare database, migrare basi di codice, ecc. Ecc. Ecc.

I peggiori pasticci sono sempre stati quando la logica aziendale era nel database. Erano sempre i più difficili da risolvere. E posso dire che mentre ho incontrato molte volte l'affermazione che "abbiamo spostato la logica nel database per le prestazioni", le prestazioni sono quasi sempre migliori con un modello di dati normalizzato pulito, buoni indici, un livello di memorizzazione nella cache di fronte al database, e algoritmi sensati implementati in un linguaggio di programmazione moderno.

Sono fermamente convinto che quando mai possibile , la logica aziendale dovrebbe essere mantenuta nel livello software e non nel livello database. Nota che quando mai possibile cade di gran lunga sempre .

Ci sono forti argomentazioni per entrambi i modi e, come sempre, usare il buon senso dell'ingegneria per decidere per ciascun progetto quanto peso deve essere applicato a ciascun punto prima di decidere quale sia la scelta più appropriata.

( come altre persone fanno le ingerenze nei commenti, possono essere aggiunti alla lista )

Argomenti per la logica aziendale di gestione del database:

• La logica aziendale ha bisogno di dati su cui operare. Ottenere l'elaborazione logica il più vicino possibile ai dati offre prestazioni migliori
• Un posto per applicare gli aggiornamenti

Argomenti relativi ai livelli software che gestiscono la business logic:

• Il software ben scritto è in genere molto più facile da capire, eseguire il debug e gestire rispetto alle stored procedure SQL.
• I server delle applicazioni possono scalare e scalare se l'applicazione Internet diventa popolare.

In qualità di sviluppatore professionista esperto, che necessita di una soluzione rapida per migliorare la latenza delle applicazioni, la scelta può essere tra lo spostamento di alcune logiche di business in una stored procedure sul database e / o per implementare il caching di processi lenti.

C'è tuttavia un serio trucco con la logica di business basata su database. Se la tua applicazione ha bisogno di scalare in maniera massiccia, preferisci sempre sistemi / processi che possono scalare (con questo voglio dire, puoi aggiungere più server nel pool di elaborazione). I database SQL possono essere scalati solo (è necessario trovare un server più potente per sostituire quello esistente). Se l'applicazione ha molte logiche di business del database, questo problema verrà raggiunto prima.

Mancano due punti molto importanti negli argomenti del tuo pro-database:

• performance : il codice del database viene eseguito con accesso diretto ai dati, evitando così trasferimenti non necessari (sia attraverso il recupero dell'API e schemi di mapping sulla stessa macchina, o attraverso la rete per la comunicazione client / server)
• consistenza : poiché diverse applicazioni possono accedere / aggiornare lo stesso database, incapsulando coerenza e regole di business al suo interno, assicura che vengano applicate in modo affidabile.

Ma alcuni punti molto importanti mancano anche sugli argomenti del tuo database:

• scalabilità : più metti sul database, più questo componente diventerà un collo di bottiglia. Naturalmente puoi prendere server più grandi e aggiungere CPU, ma prima o poi avrai i limiti fisici.

• lock-in del fornitore : SQL è molto standardizzato, ma le lingue per i trigger e le procedure sono piuttosto diversificate e spesso proprietarie: T-SQL per Microsoft, PL / SQL per Oracle, qualsiasi lingua per DB2. La creazione sul database ti blocca per un venditore e non ti consente di beneficiare di una maggiore concorrenza o di migrare verso nuovi ambienti operativi.

• architettura legacy : overcentralizzazione di dati ed elaborazione su server enormi ... Questo non ci riporta indietro nell'era dei mainframe? Ciò sembra obsoleto al giorno d'oggi, quando emergono nuove importanti tendenze architettoniche che puntano alla massima scalabilità: flessibile NoSQL database di diversi tipi ideali per lo sviluppo orientato agli oggetti , microservizi con ogni microservizio con il proprio database e un'architettura bigdata come lambda architectures dove tutte le pipeline di elaborazione sono al di fuori del database.

• argomenti obsoleti : il tempo del codice cobol ridondante incline agli errori copiato tra le applicazioni è finito. Ciò che poteva essere racchiuso in un affidabile RDBMS solo ieri, può benissimo essere incapsulato in moderne architetture software, usando componenti orientati agli oggetti manutenibili e riutilizzabili, librerie e sistemi di controllo di versione.

Per riassumere:

• sì, ci sono argomenti validi per mettere il massimo della logica sul lato del database. Ma questi argomenti non soddisfano più i nuovi bisogni e vincoli della scala di Internet, il cambiamento tecnologico e l'emergere di bigdata.
• no, non penso che esista un approccio universale ottimale. L'approccio più adatto deve essere scelto da un architetto del software, caso per caso, in base ai requisiti e alle esigenze concrete.

Oltre a tutti i fatti che sono già stati evidenziati, ricorda anche che hai una logica di business nel tuo codice piuttosto che il database alla fine risulta essere più economico.

Quando cerchi uno sviluppatore per un'applicazione scritta in PHP e usando MySQL come database, se la logica aziendale è memorizzata nel database, un semplice programmatore PHP non è sufficiente, e dovrai trovare qualcuno che sappia anche come scrivere , eseguire il debug e ottimizzare le stored procedure. All'improvviso hai bisogno di un ragazzo che sappia non solo una cosa, PHP, ma due, PHP e programmazione MySQL.

E non pensare nemmeno di passare a un motore con prestazioni più elevate come PostgreSQL , quindi devi anche assumere un ragazzo per trasformare tutte le stored procedure in PL / SQL .

Quando si utilizza la logica di business nel codice, si tratta solo di scrivere un nuovo livello di astrazione per PostgreSQL e di sostituire le dipendenze nell'applicazione, boom, l'applicazione conosce PostgreSQL.

Le risposte precedenti forniscono ottimi motivi per spiegare perché è più facile / migliore inserire la logica nel codice dell'applicazione vs in un database. Un'eccezione che vorrei sottolineare è quando si utilizza un database di big data / stack tecnologico. In questo caso, molti degli svantaggi vanno via:

• Puoi scrivere test unitari dal momento che è il codice che hai scritto che si trova nel database.
• Puoi eseguire il debug, anche se attraverso i test unitari.
• Hai il controllo della versione, poiché è il codice.

E i vantaggi di avere la logica nel database diventano molto più importanti:

• A seconda della quantità di dati trattati, potrebbe essere irragionevole inviare i dati al codice dell'applicazione.
• Ridimensionamento: il codice viene ridimensionato come le scale del database: in molti casi, le prestazioni e l'archiviazione sono lineari nel numero di nodi (macchine).

Grande domanda - questo è qualcosa che sostengo in ufficio molto regolarmente.

La mia opinione è che la maggior parte della logica dovrebbe essere nel codice. È sempre molto allettante usare una varietà di lingue perché ognuna ha i suoi punti di forza, ma a meno che tu non abbia una perfetta configurazione di sviluppo (che è molto rara), è preferibile attenersi a una lingua.

Le persone hanno menzionato la verifica delle unità di controllo / revisione delle revisioni, ma una cosa molto importante è l'implementazione. Dover sincronizzare le modifiche al codice del database con le modifiche al codice può essere pericoloso.

Se ti trovi in una società di sviluppo software su larga scala, potresti avere abbastanza persone specializzate che conoscono entrambi i lati (programmazione del database o codifica), ma altrimenti è difficile trovare persone che possano destreggiarsi tra i due mondi (e la maggior parte importante, chi fa gli scambi giusti quando si tratta di decidere quale parte della logica deve essere in quale lingua).

Personalmente, trovo i linguaggi di programmazione SQL molto primitivi e gli strumenti di sviluppo per loro ancora peggiori. Quindi preferirei linguaggi di programmazione moderni. Un buon ORM può salvare la maggior parte degli sviluppatori dal sapere qualcosa sul database, e vale la pena investire in. La gente ha menzionato l'efficienza del fare cose lato server, e questo non dovrebbe essere abbandonato. Esistono alcuni schemi di programmazione molto utili che consentono di esprimere operazioni lato server utilizzando ciò che sembra essere un'API lato client (ad esempio IQueryable in C #).

In pratica, sto ancora utilizzando le viste dispari o le stored procedure, ma di solito sono principalmente puramente per l'aggregazione e non contengono alcuna logica "aziendale". Questo è abbastanza utile in quanto possono essere utilizzati come fonti per i pivotables excel, per esempio.