Programmazione Java: dove devono essere archiviate le istruzioni SQL? [chiuso]

Dove dovrebbe memorizzare un'applicazione conforme a JDBC le sue istruzioni SQL e perché?

Finora sono riuscito a identificare queste opzioni:

• Hardcoded negli oggetti business
• Incorporato nelle clausole SQLJ
• Incapsula in classi separate, ad esempio oggetti di accesso ai dati
• Basato sui metadati (separa lo schema dell'oggetto dallo schema dei dati - descrivi le mappature tra di loro nei metadati)
• File esterni (ad esempio Proprietà o File di risorse)
• Procedura di archiviazione

Quali sono i "pro" e i "contro" per ciascuno di essi?

Il codice SQL dovrebbe essere considerato "codice" o "metadati"?

Le stored procedure devono essere utilizzate solo per l'ottimizzazione delle prestazioni o sono un'astrazione legittima della struttura del database?

La performance è un fattore chiave nella decisione? E il blocco del fornitore ?

Cosa c'è di meglio: accoppiamento lento o accoppiamento stretto e perché?

MODIFICATO: Grazie a tutti per le risposte - ecco un riassunto:

Metadata driven ie Object Relational Mappings (ORM)

Professionisti:

• Molto astratto: il server DB può essere cambiato senza la necessità di cambiare il modello
• Diffuso - praticamente uno standard
• Riduce la quantità di SQL necessaria
• Può memorizzare SQL in file di risorse
• Le prestazioni sono (di solito) accettabili
• Approccio basato sui metadati
• (Database) indipendenza dal fornitore

Contro:

• Nasconde SQL e le vere intenzioni degli sviluppatori
• SQL difficile da rivedere / modificare da DBA
• SQL potrebbe essere ancora necessario per i casi dispari
• Può forzare l'uso di un linguaggio di query proprietario, ad esempio HQL
• Non si presta all'ottimizzazione (astrazione)
• Può mancare di integrità referenziale
• Sostituisce la mancanza di conoscenza SQL o la mancanza di attenzione al codice nel DB
• Non abbinare mai le prestazioni del database nativo (anche se si avvicina)
• Il codice del modello è molto stretto accoppiato con il modello del database

Hardcoded / incapsulato nello strato DAO

Professionisti:

• SQL viene mantenuto negli oggetti che accedono ai dati (incapsulamento)
• SQL è facile da scrivere (velocità di sviluppo)
• SQL è facile da rintracciare quando sono necessarie modifiche
• Soluzione semplice (nessuna architettura disordinata)

Contro:

• SQL non può essere rivisto / modificato da DBA
• È probabile che SQL diventi specifico del DB
• SQL può diventare difficile da mantenere

Procedura di archiviazione

Professionisti:

• SQL conservato nel database (vicino ai dati)
• SQL viene analizzato, compilato e ottimizzato dal DBMS
• SQL è facile da rivedere / modificare per DBA
• Riduce il traffico di rete
• Maggiore sicurezza

Contro:

• SQL è legato al database (blocco del fornitore)
• Il codice SQL è più difficile da mantenere

File esterni (ad esempio Proprietà o File di risorse)

Professionisti

• SQL può essere modificato senza dover ricostruire l'applicazione
• Disaccoppia la logica SQL dalla logica di business dell'applicazione
• Repository centrale di tutte le istruzioni SQL - più facile da mantenere
• Più facile da capire

Contro:

• Il codice SQL può diventare non gestibile
• Più difficile controllare il codice SQL per errori (sintattici)

Incorporato nelle clausole SQLJ

Professionisti:

• Migliore controllo della sintassi

Contro:

• Si lega troppo strettamente a Java
• Prestazioni inferiori rispetto a JDBC
• Mancanza di query dinamiche
• Non così popolare

Di solito, più l'applicazione cresce in termini di dimensioni e / o riusabilità, più è necessario esternalizzare / astrarre le istruzioni SQL.

L'hardcoded (come costanti finali statiche) è il primo passo. Memorizzato in un file (proprietà / file xml) è il passaggio successivo. I metadati guidati (come fatto da un ORM come Hibernate / JPA) è l'ultimo passaggio.

L'hardcoded ha lo svantaggio che è probabile che il codice diventi specifico del DB e che è necessario riscrivere / ricostruire / ridistribuire ad ogni modifica. Il vantaggio è che lo hai in 1 posto.

Memorizzato in un file ha lo svantaggio che può diventare non più gestibile quando l'applicazione cresce. Il vantaggio è che non è necessario riscrivere / ricostruire l'app, a meno che non sia necessario aggiungere un metodo DAO aggiuntivo.

La gestione dei metadati presenta lo svantaggio che il codice del modello è molto stretto insieme al modello del database. Per ogni modifica nel modello di database dovrai riscrivere / ricostruire / ridistribuire il codice. Il vantaggio è che è molto astratto e che puoi facilmente passare dal server DB senza la necessità di cambiare il tuo modello (ma chiediti ora: quanto spesso un'azienda passerebbe dal server DB? Probabilmente almeno una volta ogni 3 anni, non è così ". vero?).

Non definirò le stored procedure una "buona" soluzione per questo. Hanno uno scopo completamente diverso. Anche se, il tuo codice dipenderà dal DB / configurazione utilizzata.

Non so se questo sia ottimale, ma nella mia esperienza finiscono con l'hardcoded (cioè stringhe letterali) nel livello DAO.

Non credo che nessuno ti darà la ripartizione pro / contro che desideri in quanto è una domanda piuttosto ampia. Quindi ecco cosa ho usato in passato e cosa userò in futuro.

Io uso per usare SQL hardcoded nel DAL. Ho pensato che andasse bene finché i DBA non hanno voluto giocare con l'SQL. Quindi devi estrarlo, formattarlo e inviarlo ai DBA. Chi ne riderà e sostituirà tutto. Ma senza i bei punti interrogativi, o i punti interrogativi nell'ordine sbagliato e ti lascio a rimetterlo nel codice Java.

Abbiamo anche usato un ORM e, sebbene questo sia ottimo per gli sviluppatori, i nostri DBA lo odiavano perché non esisteva un SQL di cui ridere. Abbiamo anche usato uno strano ORM (personalizzato da un fornitore di terze parti) che aveva l'abitudine di uccidere il database. Ho usato JPA da allora ed è stato fantastico, ma ottenere qualcosa di complicato usandolo oltre i DBA è una battaglia in salita.

Ora usiamo le stored procedure (con l'istruzione call hardcoded). La prima cosa di cui tutti si lamenteranno è che sei legato al database. Sei. Tuttavia, quante volte hai cambiato database? So per certo che semplicemente non potremmo nemmeno provarlo, la quantità di altro codice dipende da esso, oltre alla riqualificazione dei nostri DBA e alla migrazione dei dati. Sarebbe un'operazione molto costosa. Tuttavia, se nel tuo mondo è necessario cambiare DB in un batter d'occhio, è probabile che gli SP siano fuori.

Andando avanti, vorrei utilizzare le stored procedure con strumenti di generazione di codice per creare classi Java da pacchetti Oracle.

Modifica 2013-01-31 : pochi anni e DBA dopo e ora usiamo Hibernate, passando a SQL (stored procs nel DB) solo quando assolutamente necessario. Questa penso sia la soluzione migliore. Il 99% delle volte i DB non devono preoccuparsi dell'SQL e l'1% lo fanno in un posto con cui si trovano già a proprio agio.

Utilizzando un ORM (come l'ibernazione), si spera che non avrai istruzioni SQL di cui preoccuparti. Le prestazioni sono generalmente accettabili e si ottiene anche l'indipendenza dal fornitore.

Il codice SQL dovrebbe essere considerato "codice" o "metadati"?

Codice.

Le stored procedure devono essere utilizzate solo per l'ottimizzazione delle prestazioni o sono un'astrazione legittima della struttura del database?

Le stored procedure consentono il riutilizzo, anche all'interno di altre stored procedure. Ciò significa che puoi fare un viaggio al database e fargli eseguire le istruzioni di supporto: l'ideale è la quantità minima di traffico. ORM o sproc, il tempo sul filo che va al db e al ritorno è qualcosa che non puoi recuperare.

ORM non si presta all'ottimizzazione a causa della sua astrazione. IME, ORM significa anche mancanza di integrità referenziale: rende difficile creare report da un database. Ciò che è stato salvato in complessità, ora è aumentato per essere in grado di ottenere i dati in modo funzionale.

La performance è un fattore chiave nella decisione? E il blocco del fornitore?

No, la semplicità lo è. Il blocco del fornitore avviene anche con il database: SQL è relativamente standardizzato, ma ci sono ancora modi specifici del fornitore di fare le cose.

La paura del blocco dei fornitori nel mondo Java è interessante.

Spero che tu non abbia pagato $ 50000 pr CPU per Oracle Enterprise e quindi abbia utilizzato solo il minimo comune denominatore per passare a Mysql in qualsiasi momento. Come ogni buon DBA ti dirà, ci sono sottili differenze tra i diversi database di grandi nomi, soprattutto per quanto riguarda i modelli di blocco e il modo in cui raggiungono la coerenza.

Quindi, non prendere una decisione su come implementare le chiamate SQL solo in base al principio dell'SQL indipendente dal fornitore: abbi una vera ragione (commerciale) per farlo.

SQL all'interno di Stored Procedures è ottimizzato dal sistema di database e compilato per la velocità: questa è la sua casa naturale. SQL è compreso dal sistema di database, analizzato dal sistema di database. Mantieni il tuo SQL nel database se puoi; racchiuderlo in procedure o funzioni memorizzate o in qualsiasi unità logica fornita dal sistema di database, ed effettuare semplici chiamate utilizzando uno qualsiasi degli strumenti che tu o qualcun altro avete menzionato.

Perché memorizzare il codice SQL per il sistema di database fuori dal database? Spesso per velocità di sviluppo. Perché utilizzare la mappatura ORM? - Alcuni dicono che la mappatura ORM fornisce compatibilità tra diversi sistemi di database; tuttavia raramente nel mondo reale un'applicazione si sposta mai dalla piattaforma del database su di essa è stata costruita, specialmente quando inizia a utilizzare funzionalità avanzate come la replica, e per la rara occasione accade che il sistema di database venga sostituito, del lavoro è garantito . Credo che uno degli svantaggi di ORM sostituisca spesso la mancanza di conoscenza di SQL o la mancanza di attenzione al codice nel db. Inoltre, ORM non corrisponderà mai alle prestazioni del database nativo anche se si avvicina.

Sto dalla parte di mantenere il codice SQL nel database e di effettuare semplici chiamate tramite qualsiasi API o interfaccia che desideri utilizzare. Astrarre anche il punto in cui vengono effettuate le chiamate al database inserendo quelle chiamate dietro una classe astratta o un'interfaccia OO (espressa dai metodi), quindi se mai si scambia in un nuovo tipo di origine dati sarà trasparente al livello aziendale .

L'unica domanda che chiedi che ha una risposta definitiva è "È codice SQL o metadati?" È sicuramente codice e come tale dovrebbe essere mantenuto in una sorta di controllo del codice sorgente e avere un sistema per aggiornare facilmente all'ultima versione e tornare indietro quando non se le cose vanno male.

Ho visto tre modi per eseguire SQL in un'applicazione e ognuno ha i suoi pro e contro. Non esiste un modo migliore, ma la cosa migliore è sceglierne uno che funzioni bene con la tua applicazione e mantenerlo.

• ORM: riduce la quantità di SQL che devi scrivere e gestisce molti dettagli per te. Avrai bisogno di fare un po 'di SQL personalizzato. Assicurati di avere un ORM che lo gestisca con garbo.
• Oggetti di accesso ai dati: mantieni l'SQL negli oggetti che accedono ai dati. Questo incapsula il tuo database e fa in modo che il resto della tua applicazione non abbia bisogno di conoscere la struttura del database sottostante, ma solo l'interfaccia di questi oggetti.
• Stored procedure - questo mantiene tutto il tuo SQL nel tuo database e rende facile per i tuoi DBA sapere cosa sta succedendo. Tutto quello che devi fare è fare in modo che il tuo codice chiami i processi memorizzati

Ci capita di utilizzare il mapper SQL iBatis, che è più vicino al metal rispetto a ORM come Hibernate. In iBatis metti le istruzioni SQL in file di risorse (XML), che devono essere nel classpath.

Il tuo elenco di approcci sembra piuttosto completo se aggiungi l'opzione ORM di @ ocdecio. Direi che l'utilizzo di un ORM e l'utilizzo di un mapper SQL e dei file di risorse sono i due approcci migliori. Eviterei SQLJ, che non ha visto molto assorbimento e ti lega troppo strettamente a Java. Evita anche le stored procedure, poiché ti legano a un fornitore di database specifico (gli standard sono quasi inesistenti per le stored procedure).

Come la maggior parte di noi, ho visto l'intero gammut ma dobbiamo considerare SQL un linguaggio di prima classe. Ho persino visto l'SQL memorizzato nel DB che viene tirato giù e poi eseguito di nuovo.

I sistemi di maggior successo che ho visto utilizzano stored procedure, funzioni e visualizzazioni.

Le procedure memorizzate mantengono il testo SQL nel DB e consentono modifiche relativamente immediate da parte di coloro che DEPLOYING e PERSONALIZZA (che richiede un sacco di progettazione adeguata per supportarlo).

Tutte le proiezioni dovrebbero avvenire tramite viste e selezioni semplici per gli stessi motivi, tutta la logica di proiezione dovrebbe essere contenuta nella vista.

Suggerisco di utilizzare DAO con un layout di fabbrica. Quindi gli oggetti di esempio di cui hai bisogno sarebbero:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

Questo stile stratifica l'interazione dei dati, quindi dovresti cambiare solo un livello di codice se cambi database o passi alle tecnologie ORM.

Non c'è davvero alcuna differenza sostanziale tra questi tre:

1. Hardcoded negli oggetti business
2. Incorporato nelle clausole SQLJ
3. Incapsula in classi separate, ad esempio oggetti di accesso ai dati

Presumo che incorporerai il codice SQL in una stringa direttamente nel tuo codice Java. Mentre 1 e 3 probabilmente useranno JDBC direttamente (o qualche strumento come Apache DbUtils ), 2 aggiunge una tecnologia di preprocessore allo stack, generando il codice JDBC pertinente prima della compilazione.

Quindi, in sostanza, se queste soluzioni implicano l'incorporamento di SQL, potresti anche utilizzare una qualsiasi di queste tecnologie:

• API JPA Criteria , che modella JPQL come linguaggio specifico del dominio interno in Java
• jOOQ , modellando SQL come linguaggio specifico del dominio interno in Java

Potrebbero esserci anche altri strumenti per aiutarti a incorporare SQL in Java in un modo più sicuro rispetto ai tipi che tramite SQLJ o tramite concatenazione di stringhe.

Da quale esperienza ho avuto, le istruzioni sql hardcoding negli oggetti DAO è ciò che è ampiamente utilizzato, tuttavia, penso che dovrebbe essere il metodo meno preferito. La procedura migliore dovrebbe essere quella di memorizzare le istruzioni sql in un file delle proprietà. E ottieni le istruzioni nell'oggetto DAO tramite un'interfaccia ai file delle proprietà, ad esempio java.util.Properties . Le istruzioni sql possono essere intervallate da "?" Per passare i parametri, attraverso un approccio di istruzione preparata .

Un tale approccio aiuta a separare la logica sql dalla logica di business dell'applicazione. Ciò rende disponibile un repository centrale di tutte le istruzioni sql, che semplifica la modifica, eliminando la necessità di cercare le istruzioni del database all'interno della logica dell'applicazione. Anche la comprensione migliora.

I miei finiscono in pacchetti di risorse. So che non è normale, ma è la cosa più facile da mantenere per me e per chiunque "diverso da me". È semplice e logico.

In realtà sono curioso di vedere se qualcuno usa anche il mio approccio.

Come un rexem scritto le istruzioni SQL sono codice: dovrebbero essere trattate come codice, non esternalizzate (a meno che tu non abbia una buona ragione) ma collocate con codice che elabora dati SQL da / a quelle istruzioni. Il framework di oggi ORM / iBatis offre molte semplificazioni per lo sviluppo JDBC quotidiano.

Alcune risposte alla tua domanda le troverai in questa domanda :) Il problema di come verranno memorizzate le tue istruzioni SQL dipende dal tipo della tua applicazione. Quali sono le tue esigenze? Elevata sicurezza, facilità di scrittura del codice o manutenzione, multipiattaforma o vincolo del fornitore? La prossima domanda che ti serve è un framework SQL o ORM puro?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

Soluzione più semplice (P), difficile da mantenere (C)

* Embedded in SQLJ clauses

Migliore controllo della sintassi (P), mancanza di query dinamiche (C), prestazioni inferiori a JDBC (C), non così popolare (C)

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

Deve essere un caso specifico in cui dovresti farlo (C) o se intendi ORM (P);)

* External files (e.g. Properties or Resource files)

Facile da mantenere (P) ma più difficile da controllare per errori (C)

* Stored Procedures

Alta sicurezza (P), codice difficile da mantenere problemi di blocco del fornitore (C)