Il modo migliore per organizzare le query SQL memorizzate nel tuo codice? (o dovresti?) [chiuso]

Question

Il modo migliore per organizzare le query SQL memorizzate nel tuo codice? (o dovresti?) [chiuso]

#1 da (10 voti)
#2 da (0 voti)
#3 da (0 voti)

13

Sono sicuro di non essere l'unico ad essere frustrato quando vedono una pagina di codice piena di query SQL. ActiveRecord e altri schemi ORM aiutano a mitigare una buona quantità di SQL utilizzato in un progetto, ma in molti casi di query complesse, l'uso di SQL è apparentemente inevitabile.

Sto cercando opinioni su come le query SQL dovrebbero essere organizzate con il resto del codice (o esternamente ad esso) per evitare che si diffondano ovunque? Un'idea ovvia è l'uso di Views, ma spesso Views può essere una fonte di problemi di prestazioni quando si ha a che fare con più tabelle indicizzate di grandi dimensioni, ecc.

MODIFICA 1 - Presumo che tu abbia già ottenuto la separazione nel livello del modello

code-formatting sql

posta jellyfishtree 13.12.2010 - 01:59

fonte

3 risposte

0

Generalmente, avere un livello di modello separato è l'approccio migliore. Esistono numerosi modelli di progettazione aziendale che danno modo di architettarlo.

risposta data 13.12.2010 - 02:05

fonte

0

Potrebbe essere una buona idea separare il tuo livello di modello in 3 sottostrati: "entità", "repository" e "servizi". Ciò ti consentirà di separare le preoccupazioni e raccogliere SQL in un unico posto, fuori dalla tua logica aziendale.

In questo scenario, tutti i codici di recupero dei dati, incluso SQL complesso, si troveranno nei repository. Quindi l'obiettivo di repository è quello di nascondere istruzioni SQL complesse dietro metodi auto-esplicativi come% % co_de.

Le estensioni di entità reali di nomi di campi di tabelle DB con getter e setter possono fornire una conversione di dati tra tipi di campi DB e tipi disponibili nell'applicazione / nel linguaggio di programmazione. Se il tuo ORM lo supporta, le entità possono gestire le associazioni.

Il livello di servizio è il posto per la logica aziendale. Il servizio recupera le entità che utilizzano repository, agisce su di esse e le archivia indietro.

risposta data 27.07.2014 - 22:08

fonte

Leggi altre domande sui tag code-formatting sql

Quando usare typedef? Cercando di capire il 2N lNN confronta per quicksort

score 10 · Accepted Answer

Per me, SQL è una parte fondamentale (in molti casi, la maggior parte) del codice di logica aziendale. Se si tenta di separarlo dal codice che opera sui dati restituiti, si è più inclini a sbilanciare la comprensibilità e la manutenibilità del codice.

Mentre lo guardo, sto leggendo dati, elaborando dati, scrivendo dati, cercando dati ... sono tutte operazioni simili, e meglio conservate nello stesso luogo.

Se inizi a percepire una duplicazione degli sforzi con le query, allora forse hai bisogno di una vista del database o di un oggetto che possa incapsulare quell'aspetto dell'accesso al database.

Un altro suggerimento è di avere un buon metodo di interrogazione del database. Nel software che scrivo (PostgreSQL, MySQL, SQL Server), ho assicurato che la maggior parte delle mie operazioni di interrogazione può avvenire come una singola istruzione di codice.

GetValue(SQL, [transaction], [array_of_params])
GetRow(SQL, [transaction], [array_of_params])
GetRowList(SQL, [transaction], [array_of_params])
GetValueList(SQL, [transaction], [array_of_params])
Execute(SQL, [transaction], [array_of_params])

Queste sono (approssimativamente) le chiamate alle funzioni principali che cerco fanno parte del mio "oggetto connessione". Dipende dal linguaggio, da ciò che effettivamente implemente, ma il mio punto è di mantenerlo davvero, molto semplice e indolore.

In sintesi, considera SQL come parte nativa della programmazione e non astratti per motivi di astrazione.