Manipolazione diretta del database e anti-pattern?

L'uso dell'approccio che richiede il 100% dell'interazione del database da eseguire attraverso stored procedure è in realtà una cattiva idea, direi. Il database dovrebbe essere per la memorizzazione di "dati" (tra le solite funzionalità CRUD e proprietà ACID), non per memorizzare le procedure per incapsulare l'intero database. Alcuni motivi per cui questa è una cattiva idea includono:

• test lenti (supponendo che tu stia scrivendo test)
• probabilmente più difficile da testare (supponendo che tu stia scrivendo test)
• è richiesto un grande sforzo se si cambiano i DBMS o, in altre parole, si possono associare a un unico fornitore DBMS
• impegno o addirittura possibilità di passare a un fornitore o meccanismo non basato su SQL per archiviare dati

Tuttavia, dovresti anche considerare in che modo "probabile" o meno che le cose sopra possano accadere durante il ciclo di vita del tuo progetto quando prendi la tua decisione.

La risposta a questa domanda è "dipende".

Se le stored procedure non stanno facendo niente di speciale di UPDATE , INSERT , DELETE o SELECT senza alcuna logica speciale intorno a loro, quindi usando Stored Procedures è un Anti Pattern perché la maggior parte delle ORM farà questo per te.

Se hai una mezza dozzina di applicazioni scritte in diverse lingue che salvano i dati su una determinata tabella e ogni applicazione duplica alcune logiche di business attorno agli INSERT e agli UPDATE, quindi non utilizzando stored procedure è un anti modello.

La regola generale che uso è Do not Repeat Yourself . Se esiste una logica aziendale comune che deve essere utilizzata da più applicazioni e tali applicazioni non possono utilizzare le librerie condivise o utilizzare le librerie condivise diventa un problema di manutenzione, quindi utilizzare sempre una stored procedure.

Se la stored procedure non sta facendo nulla di più di un ORM, allora una stored procedure è come colpire una puntina con una mazza. Stai creando più lavoro per il programmatore di quanto sia necessario.

unnecessarily couples application and storage code

È meglio che accoppiare la tua app ad un particolare database? Penso che la grande domanda sia: voglio unire i miei sviluppatori al database?

Se lavorerai con un database, penso che dovresti capire come funziona il codice, ma ciò non significa che lo sviluppatore debba scrivere direttamente ogni singola istruzione. Usare il linguaggio di scelta è abbastanza difficile senza il lavoro aggiuntivo di scrivere sql. La maggior parte dei programmatori separerebbe le preoccupazioni inserendo la logica del dominio (cosa fa realmente l'app) e la memorizzazione all'interno dell'applicazione. Esistono framework che si occupano di molte "risorse di database" per il programmatore e possono persino utilizzare lo stesso codice e passare da un RDBMS a un altro. Aggiungi una proprietà a un modello di dati e lascia che l'ORM crei una posizione nel database.

Vantaggi della stored procedure Contengono il testo per uno script. Sì, è stato controllato dal db per vedere se verrà eseguito (notare che non ho detto che funzioni). Come tutte le query inviate a molti database, cercherà di memorizzare nella cache alcuni piani di esecuzione per le prestazioni (la procedura di archiviazione non è richiesta). La tabella e altri accessi agli oggetti possono essere bloccati e controllati nella sproc per utenti / gruppi. Sono d'accordo, che grande caratteristica. Perché un programmatore dovrebbe preoccuparsi di tutto questo nel codice dell'app. Scaricalo dal database in modo simile ad alcuni servizi Web o altre API.

Ecco perché questa è una cattiva idea per molti sviluppatori. Non vogliono scrivere sql e avere un DBA amabile 24/7 è difficile da trovare. Lo sviluppo del database può diventare un collo di bottiglia. Quando è necessario un requisito o si trova un bug, il nome del film è "Amico! Dov'è il mio codice?" è tutto nella sezione del dominio.

RDBMS non piace Sorprese: ecco perché alcuni tipi di codifica non sono adatti alla maggior parte dei linguaggi di scripting del database Se solo questo ha funzionato:

Seleziona @ListOfFields FROM @TheTableOfYourChoice WHERE @TheColumnYouWant = @OnlyParameterValueWhichWouldActuallyWork;

Tanto più che questa stored procedure che fa in modo che tutto il materiale del database suoni così bene, ci sono dei limiti. Buona fortuna scrivere la dichiarazione di sql per l'opzione di filtro a 8 parti che il tuo cliente desidera. "Ma cosa succede se ho bisogno di cercare il nome completo o solo l'abbreviazione e possibilmente il numero di telefono? Potrebbe succedere."

Direi che la manipolazione diretta del database è spesso una cosa negativa. Non so se è un anti-pattern però. Credo che pattern e anti-pattern siano parole d'ordine sovrautilizzate.

L'unico svantaggio del disaccoppiamento è che un buon livello di astrazione richiede più tempo di sviluppo e può essere eccessivo per le piccole applicazioni.

Il livello di astrazione tra un'applicazione e un database non ha bisogno di essere stored procedure. Potrebbe essere "middleware". Conosciuto anche come libreria o servizio che esegue azioni di database per l'applicazione.

La cosa positiva è che le modifiche non devono essere rifatte attentamente in ogni applicazione che accede al database.

Ad esempio, supponi di avere un browser Web che utilizza un database locale per memorizzare la cronologia di navigazione e i segnalibri. E non puoi semplicemente aggiungere un segnalibro con un INSERT perché esiste una relazione complicata tra tre diverse tabelle. Una piccola libreria può essere utilizzata dal browser e da uno strumento da riga di comando per rendere le modifiche ai segnalibri facili da scrivere anziché complicate e soggette a rottura con ogni aggiornamento.

(Si noti che la "piccola libreria" a mio parere esclude molti ORM di Java. Ho visto uno strumento da riga di comando che impiegava 10 secondi per avviarsi e richiedeva l'accesso a 12 file JAR e di configurazione. o così INSERIRE e AGGIORNA comandi. Ridicolo.)

Anche l'astrazione dell'accesso al database in un servizio può migliorare le prestazioni. Ci sono state molte app di desktop business scritte che parlano di un database su una VPN. Con un ritardo di 120 ms tra ciascuna SELECT, UPDATE, INSERT, ecc. L'invio di una singola richiesta che esegue localmente una serie di comandi del database è molto più veloce.