Memorizzazione di SQL dinamico in file di testo rispetto a codice inline

7

Il nostro team di architettura sta proponendo un framework che vedrebbe le nostre query SQL spostate da stringhe codificate all'interno delle nostre applicazioni, in un sistema basato su file in cui li invochiamo con chiamate di funzione. La nostra applicazione fa un uso pesante delle query SQL che vanno dal banale, a molto complesso. Questa è una soluzione .NET.

L'idea è che ogni query verrà scritta in file di testo e saremo in grado di taggare campi, join e condizioni con attributi. Quando chiamiamo le nostre funzioni SQL, potremmo passare argomenti per attivare / disattivare questi attributi in base alla nostra logica aziendale, consentendo solo l'esecuzione delle parti dell'SQL.

Sebbene mi piaccia l'idea di astrarre il nostro SQL, sono scettico sul fatto che questo sistema possa portare a benefici tangibili. Il driver principale di ciò è la nostra esperienza passata in cui molti programmatori hanno creato alcune funzioni SQL dinamiche pasticciate in modo massivo che erano impossibili da comprendere. L'idea è che questo renderà più semplice la definizione delle query, renderà più facilmente controllabili tutte le query e definirà chiaramente la logica di business coinvolta. Non sono sicuro che sopravviverà alla prova della realtà.

Mi piacerebbe avere un feedback sui pro / contro di questo approccio.

Inoltre, prima che qualcuno lo suggerisca, Entity Framework è stato rifiutato a causa del supporto discutibile del nostro provider di database (Teradata).

    
posta Brett Emerson 21.12.2012 - 15:31
fonte

4 risposte

4

Se il tuo problema è "impossibile capire" SQL, concentrati su quel problema. Non riesco a immaginare che SQL con attributi faccia nulla per renderlo più facile da capire.

Invece creerà un carico di manutenzione sull'analisi degli attributi, ecc. su un linguaggio già complesso come sql. Prima o poi le tue estensioni ti impediranno di utilizzare alcune funzionalità del database. Quanta formazione è necessaria per insegnare ai nuovi dipendenti / appaltatori la tua versione di sql? I file aggiuntivi creano un processo di distribuzione più complicato e possibili problemi di supporto. Come si conosce la versione del file in uso o se è stata modificata dal cliente o dal proprio supporto per risolvere un altro problema? Ovviamente tutto può essere risolto, ma solo tu sai se ne vale la pena.

Trascorri il tuo tempo impostando rigorose linee guida per scrivere SQL leggibile / gestibile. Una volta che è a posto e tutti sono d'accordo sulle regole, puoi passare al problema successivo.

Ciò che è sql leggibile e gestibile varia ma qui c'è un sottoinsieme delle nostre regole. (Per sql-server)

  • devi essere in grado di copiare / incollare facilmente il codice nel / dal database ed eseguirlo Cioè Nessuna concatenazione di stringhe di variabili nel codice. Usa parametri o stringa. Sostituisci dove i parametri non sono consentiti in sql.
  • una colonna per riga preceduta da tabella / alias
  • esplicito AS
  • ansi si unisce
  • alias descrittivi (non t1, t2 ecc.)
  • usa CTE / CROSS APPLY per ridurre la complessità
  • usa i parametri con un nome descrittivo per entrambe le variabili e i numeri "magici".
risposta data 21.12.2012 - 23:19
fonte
4

Mi sono imbattuto in questo stesso dilemma sul mio lavoro da un po 'di tempo fa. Ho ricevuto lo stesso consiglio che hai fatto, ed ecco cosa ho pensato a riguardo:

Pro:

  • Le query SQL possono essere testate separatamente, separate dal codice della linea principale.
  • Le tue query possono essere modificate senza doverle ricompilare.

Contro:

  • SQL è codice. Trovo più facile da gestire quando tutto il codice che fa qualcosa si trova nello stesso posto.
  • Ho trovato raro modificare una query SQL senza la corrispondente modifica del codice della riga principale.

Ho deciso che i contro erano superiori ai professionisti e hanno lasciato l'SQL nella sorgente principale . È passato circa un anno da quando ho preso questa decisione e non me ne sono pentito una volta.

    
risposta data 21.12.2012 - 15:42
fonte
2

Se hai detto che gli architetti volevano estrarre l'SQL e inserirlo nelle stored procedure all'interno del database, avrei detto "Dai ai ragazzi un biscotto!". Ma passare dall'SQL assemblato tramite la costruzione di stringhe a SQL assemblati tramite il template è un passo troppo piccolo per meritare una ricompensa.

    
risposta data 21.12.2012 - 23:31
fonte
0

One BIG Pro.

È possibile supportare più DB semplicemente sostituendo i file SQL. Quindi hai più serie di codice SQL per il diverso DB che vuoi supportare.

    
risposta data 21.12.2012 - 16:57
fonte

Leggi altre domande sui tag