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é non solo sono state implementate 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.
Rimane davvero 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 !!!
Lo sviluppatore codifica SP e utilizza metodi iterattivi. DBA guarda la 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 la chiamata di altro codice BL correlato o SQL che non segue i normali piani di esecuzione dell'istruzione SQL.
Alla luce di ciò, la configurazione, l'ottimizzazione delle prestazioni e la codifica SP diventano 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, più sviluppatori e 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.