it-swarm.it

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

[~ # ~] note [~ # ~] Il pubblico di programmers.se e dba.se è diverso e avrà punti di vista diversi, quindi in questa istanza penso che sia valido duplicare Quali sono gli argomenti a favore o per mettere la logica dell'applicazione nel livello del database? su programmers.se.

Non ho già trovato discussioni su dba su questo, e il post originale dice tutto, quindi:

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 facilitare 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?

N.B. Non sono l'OP per quella domanda, ma ho lasciato intatta la formulazione originale.

74
Phil Lello

Pensieri assortiti ...

Il codice del database sopravviverà alla tecnologia client dell'applicazione. Pensa a ADO.NET -> Linq -> EF e ORM assortiti. Considerando che è ancora possibile eseguire il codice SQL Server 2000 dall'ultimo millennio su tutte le tecnologie client di cui sopra.

Hai anche il problema con più client: ho .net, Java ed Excel. Sono 3 serie di logiche applicative.

La "logica di business" non deve essere confusa con la "logica di integrità dei dati". Se hai clienti che iniziano transazioni e fanno assegni assortiti, ci sono molte chiamate db e una transazione lunga.

La logica dell'applicazione non viene ridimensionata per volumi di dati elevati. Abbiamo 50k righe al secondo usando i proc memorizzati. Una squadra sorella che utilizza Hibernate non può ottenere no al secondo

56
gbn

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'ultimo Fortune 500 a cui ho lavorato ha avuto applicazioni scritte in almeno 25 lingue colpendo il loro OLTP. Alcuni di questi programmi sono passati alla produzione negli anni '70.

L'alternativa all'implementazione di questo tipo di requisiti nel database è quella di consentire a tutti i programmatori di applicazioni di reimplementarli in tutto o in parte al 100% correttamente, ogni volta che accendono il loro editor, dal giorno in cui camminano per la prima volta fino a quando la società esce attività commerciale.

Quali sono le probabilità?

Non è questo il singolo più grande " non ripeterti " sul pianeta?

Sto spostando la mia vecchia risposta inedita da programmers.se, poiché le risposte sembrano piuttosto polarizzate tra i siti.

So di essere qui per un mondo ferito, ma inserisco la logica aziendale nel database perché:

  • Puoi consentire agli utenti business power l'accesso diretto al database e non preoccuparti che si rovinino (o preoccupati meno di quanto faresti con la logica basata su app)
  • Un utente esperto può creare nuovi report senza attendere una nuova versione del software.
  • Puoi testare SP/codice TRIGGER in una copia del database, proprio come test della logica basata su app
  • Puoi mantenere l'SQL per creare sp e trigger in file di testo (dovresti farlo comunque per il codice tabella/vista)
  • È possibile combinare e abbinare le lingue senza eseguire il porting della logica aziendale
  • È possibile apportare modifiche alla logica aziendale senza aggiornare ogni bit di software
  • La struttura di controllo cambia nello stesso modo in cui si verifica l'attività del database, mediante la registrazione
  • Sicurezza notevolmente migliorata e controllo di accesso accurato (la maggior parte delle implementazioni logiche basate su app utilizzano il proprio modello di sicurezza, quindi i dati sono molto più facili da compromettere. La crittografia della password reversibile non è rara)
  • La sicurezza dell'utente lato database riduce notevolmente il danno/furto che SQL può fare

I contro sono: - Gli sviluppatori minacciano quando gli utenti diventano meno dipendenti dagli sviluppatori per i report personalizzati - Gli sviluppatori devono imparare un altro linguaggio di programmazione

Nessuno di questi dovrebbe essere importante per uno sviluppatore esperto.

Interessante da notare, la maggior parte delle risposte parla in termini di "logica dell'applicazione", non di "logica aziendale", come se il software non fosse presente per fornire una funzione aziendale.

29
Phil Lello

Il problema più importante è se qualsiasi "livello" sopra il database pensa di possedere i dati. La concorrenza e l'integrità dei dati sono problemi per i quali la soluzione è un RDBMS: alcune applicazioni sono sviluppate come se il database fosse solo il loro bit bucket personale e, naturalmente, finiscono per provare a reinventare la ruota in tutti i modi, nonché essere irreparabilmente interrotto non appena un'altra applicazione accede allo stesso database

Ho scritto la mia risposta a questo nel mio blog . La mia conclusione è, farlo nell'applicazione non si ridimensiona una volta considerato l'intero ciclo di vita dell'applicazione.

...
3. Aggiungi vincoli di integrità/verifica al database sottostante, con codice più complesso implementato nella lingua della procedura memorizzata del database. Da questo abbiamo una posizione centrale da mantenere e otteniamo l'applicazione assoluta delle regole anche per le applicazioni che non conosciamo! Otteniamo una lingua in cui esprimere le regole aziendali in tutto il portafoglio di applicazioni e il ciclo di vita, poiché la lingua del giorno cambia molto più spesso rispetto al database. Funziona su un sistema già critico come le applicazioni più importanti. Gli errori sono gestiti dal codice esistente che gestisce gli errori del database in tali applicazioni. Esiste ancora il rischio che un'applicazione si rompa naturalmente, ma dei tre scenari, questo è il minimo, e solo l'applicazione non funzionante necessita di modifiche, non tutte (e la maggior parte dei meccanismi di SP/database consentirà un'eccezione fatto per un'applicazione se è davvero, davvero necessario). Pensi che questo non abbia importanza nel tuo sito greenfield o piccola azienda? Bene, se la tua attività ha successo, tra 30 anni vorrai aver prestato attenzione alla mia saggezza!

... Alcune [obiezioni] che sento spesso:

  • È difficile controllare la versione SP distribuito nel DB. Non credo sia più vero che dire che è difficile da controllare con la versione Java distribuito in un server di app, vale a dire, non è affatto difficile, è un luogo comune. E oltre in Ruby-land, interi libri sono scritti quasi come ottenere il codice da un ambiente di sviluppo alla produzione, qualcosa con cui nessun'altra comunità linguistica sembra lottare. Eppure la versione che controlla una procedura memorizzata è apparentemente troppo difficile.
  • Le procedure memorizzate sono difficili da testare. Questa è strana. Per cominciare, gli SP sono fortemente tipizzati; il compilatore ti dirà se esiste o meno un percorso di codice che non ha senso e, almeno in Oracle, calcolerà tutte le dipendenze per te. Quindi questo è un insieme di test di unità comuni che potresti aver bisogno in Ruby eliminato dal pipistrello. Per testare OO richiede derisione per forzare l'oggetto nello stato interno richiesto per rappresentare lo scenario di test - in che modo l'impostazione dei dati di test è diversa? Esiste anche un produttore TAP per PL/SQL e altri strumenti, oltre a debugger e profiler.
  • Una lingua della procedura memorizzata non è una lingua completa. Bene, non stiamo cercando di scrivere un'intera applicazione solo nelle procedure memorizzate! I più dedicati SP hanno tutti i costrutti moderni che ti aspetteresti, e almeno in Oracle puoi usare Java Stored procedure con tutte le funzionalità del linguaggio = OO gli sviluppatori hanno familiarità con, o procedure esterne in qualsiasi lingua. Ciò che conta è dove viene implementata la logica - in un posto, vicino ai dati - il linguaggio reale è solo un dettaglio. PL/SQL compila il codice nativo ed esegue in-process con il database; non esiste un'architettura con prestazioni più elevate di quella.
  • Non voglio imparare un'altra lingua. Trascurare per un secondo questa è un'enorme bandiera rossa in qualsiasi sviluppatore (specialmente uno che propone di modificare la produzione app che potrebbero essere in altre lingue!) c'è molto da imparare a lavorare in qualsiasi ambiente moderno: un tipico Java potrebbe avere Eclipse, WebLogic, Maven, Hudson, Anthill, Subversion, e una pletora di altri, che devi imparare prima di scrivere una singola riga di codice dell'applicazione. Una conoscenza pratica di un livello molto alto SP è semplice in confronto, e ci sarà più di probabilmente uno specialista o un DBA in giro per aiutarti. Per non parlare del fatto che il preferito dagli sviluppatori Hibernate arriva con il suo linguaggio di query ...

...

17
Gaius

SQL fa cose come impostare la logica e il filtraggio dei risultati orientato all'applicazione? SQL è un linguaggio di manipolazione set meraviglioso.

Inoltre, come indicato in precedenza da GBN, il codice SQL sopravviverà quasi universalmente al codice dell'applicazione.

Sebbene sia vero che EF o NHibernate o LinqToSql o qualsiasi altra cosa ti consentano di generare codice più velocemente, ogni programmatore degno delle sue prestazioni sa che solo l'ottimizzazione dell'SQL ottimizzerà il recupero dei dati. RDBMS capisce solo SQL, quindi devi trasformare tutto in SQL prima che sia detto e fatto. (supponendo che possiamo concordare sul fatto che TSQL e PLSQL sono ancora SQL)

12
jcolebrand

Uno svantaggio che le persone non stanno necessariamente discutendo - i professionisti sono stati esauriti qui - è il costo.

Le CPU sul server di database sono spesso le CPU più costose in qualsiasi organizzazione quando si paga il costo della licenza del software. Quindi spostare la logica di business al livello dati è qualcosa che dovrebbe essere fatto con giudizio, non necessariamente in modo uniforme.

11
Adam Musch

Qui è dove l'incontro delle menti, vale a dire le menti degli sviluppatori (DV) e dei DBA, deve inevitabilmente avvenire. Lavorare con Business Logic (BL) e archiviarlo in un database può avere un impatto che può glorificare o sconvolgere la sua implementazione.

Per alcuni prodotti RDBMS, esistono librerie/strumenti/API superiori per la logica aziendale e le infrastrutture di oggetti che si possono apprendere e impiegare rapidamente nelle loro applicazioni. Per altri RDBMS, non esistono librerie/strumenti/API.

In passato, le app del server client trasformavano il bridge in BL tramite Stored Procedures (SP). Per prodotti come Oracle e SQL Server, questo è stato fatto in anticipo. Con la creazione di database open source come PostgreSQL e MySQL, quelli che li utilizzavano rischiavano di aprire nuove strade con le procedure memorizzate in BL. PostgreSQL è maturato molto rapidamente in questo, poiché sono state implementate non solo le procedure memorizzate, ma anche la capacità di creare le lingue dei clienti. MySQL sostanzialmente ha smesso di evolversi nel mondo delle procedure memorizzate ed è arrivato in una forma ridotta di un linguaggio con molte restrizioni. Pertanto, quando si tratta di BL, si è completamente in balia di MySQL e del suo linguaggio Stored Procedure.

Resta solo una domanda: indipendentemente dal RDBMS, BL dovrebbe risiedere in tutto o in parte nel database?

Pensa allo sviluppatore. Quando le cose vanno male in un'applicazione, il processo di debug farà entrare e uscire dallo sviluppatore da un database per seguire le variazioni di dati che possono essere o meno corrette in modo intermittente. È come codificare un'applicazione C++ e chiamare il codice Assembler nel mezzo. Devi passare da codice sorgente, classi e strutture a interruzioni, registri e offset E INDIETRO !!! Questo porta il debug allo stesso livello.

Gli sviluppatori potrebbero essere in grado di elaborare un metodo ad alta velocità per eseguire BL in combinazione con le configurazioni del linguaggio (flag del compilatore per C++, impostazioni diverse per PHP/Python, ecc.) Tramite oggetti business che si trovano in memoria anziché in un database. Alcuni hanno provato a collegare questa ideologia per un codice runnng più veloce nel database scrivendo librerie in cui il debug di Stored Procedure e trigger è ben integrato nel database e apparentemente utilizzabile.

Pertanto, allo sviluppatore viene richiesto di sviluppare, eseguire il debug e mantenere il codice sorgente e BL in due lingue.

Ora pensa al DBA. Il DBA vuole mantenere il database snello e significare il più possibile nel regno delle procedure memorizzate. Il DBA potrebbe vedere BL come qualcosa di esterno al database. Tuttavia, quando SQL richiede i dati necessari per BL, SQL deve essere snello e medio.

Ora, per l'incontro delle menti !!!

Codici sviluppatore SP e utilizza metodi iterattivi. DBA esamina SP. DBA determina che una singola istruzione SQL può sostituire i metodi iterattivi scritti dallo sviluppatore. Lo sviluppatore vede che l'istruzione SQL suggerita dal DBA richiede chiamando un altro codice BL o SQL che non segue i normali piani di esecuzione dell'istruzione SQL.

Alla luce di ciò, la configurazione, l'ottimizzazione delle prestazioni e SP diventa una funzione della profondità e dell'intensità dei dati di BL per il recupero dei dati. Maggiore è la profondità e l'intensità dei dati del BL, il più Gli sviluppatori e il DBA devono trovarsi sulla stessa pagina per la quantità di dati e la potenza di elaborazione fornita al database.

CONCLUSIONE

Le modalità di recupero dei dati dovrebbero sempre coinvolgere sia i campi degli sviluppatori sia i campi DBA. Si devono sempre fare delle concessioni su quali metodi di codifica e paradigmi di recupero dei dati possano lavorare insieme, sia per la velocità che per l'efficienza. Se la preparazione dei dati da gestire per il codice sorgente viene eseguita una sola volta prima che il codice ottenga i dati, il DBA dovrebbe dettare l'uso di SQL snello e medio. Se il BL è qualcosa con cui il DBA non è in sintonia, le redini sono quindi nelle mani dello sviluppatore. Questo è il motivo per cui il DBA dovrebbe vedere se stesso e parte del team di progetto e non un'isola per se stesso, mentre lo sviluppatore deve consentire a DBA di perfezionare l'SQL se lo giustifica.

7
RolandoMySQLDBA

È una bella domanda da porre in un sito Web pieno di DBA. Speriamo che la maggior parte delle risposte siano "pro" per mantenere il database in uno stato ACID, e quindi mantenere la logica di business nel database. : -)

Per quanto riguarda la mia opinione, penso che dovresti implementare la logica di business sia nelle tue applicazioni che nei tuoi database. Questo approccio avrà un costo maggiore in termini di tempo e denaro, ma di conseguenza penso che avrà una soluzione di business qualitativa migliore.

4

Come ha detto Adam Musch sopra, c'è altro da considerare qui per la performance. Uso della CPU. Utilizzo della memoria.

Blocca ovviamente cose sbagliate dal raggiungere il database.

  • Elimina gli indirizzi email che non sono conformi in qualche modo di base.
  • Controlla le lunghezze

Quando si approfondisce, è necessario prendere le decisioni. Il server DB è un posto molto costoso per fare cose che il client potrebbe fare facilmente. esempio: formattazione dei dati, formattazione delle date, assemblaggio di stringhe, ecc. lato client.

Ti occupi di matematica/elaborazione sul client o sul server DB? Per me ciò dipende dalla complessità e dal numero di record coinvolti. La logica aziendale dovrebbe davvero essere eseguita nel DB stesso in modo che tutto sia trattato allo stesso modo.
Dovresti davvero creare un'API di viste per leggere e archiviare i proc per scrivere i dati nel DB per salvarti il ​​mal di testa in futuro.

Usa i punti di forza di ciascuna estremità a tuo vantaggio.

2
Matt M