Come faccio a gestire un numero così elevato di query SQL?

Question

Come faccio a gestire un numero così elevato di query SQL?

#1 da (8 voti)
#2 da (7 voti)

5

Ho un progetto MVC3 che utilizza SQL Server.

Uso sempre i dati dal database SQL e spesso scopro che sto riutilizzando / duplicando alcune query SQL. Ho pensato di risolvere questo problema creando alcune classi statiche di "helper" che contengono solo una serie di metodi statici per il recupero di cose comuni.

GetAllUsers(database As MyEntity)
GetAllNonActivatedUsers(database As MyEntity)
GetUser(database As MyEntity, userId As Integer)

Il problema è che questo ha reso le cose leggermente peggiori. Ora invece di avere query SQL su tutte le azioni del mio controller, ci sono un gran numero di queste in queste classi helper. I nomi di questi metodi stanno diventando sciocchi.

GetPendingUserApplicationByApplicationId(database as MyEntity,
    applicationId As Integer, userId As Integer)

In questa fase sto pensando di eliminare le classi helper e tornare a query SQL casuali in tutte le azioni del mio controller.

Dove ho sbagliato e in che modo le persone gestiscono le loro query SQL?

È corretto duplicare le query SQL?

code-quality refactoring asp.net-mvc code-smell vb.net

posta Rowan Freeman 12.03.2013 - 23:15

fonte

2 risposte

7

Molte persone oggigiorno (basate esclusivamente sulla mia esposizione professionale) ora stanno utilizzando gli strumenti ORM per i benefici che forniscono.

I vantaggi includono:

Caricamento lento
Target di database multipli
Per alcuni framework, uso di LINQ per selezionare i record (ad esempio Linq-to-SQL, Entity Framework)
Non è necessario modificare più query quando aggiungi un campo

Il negativo principale per quanto mi riguarda è una curva di apprendimento ripida, tuttavia Linq-to-SQL è abbastanza semplice.

Dato che stai utilizzando ASP.NET MVC, ti suggerisco di consultare Tutorial di Entity Framework Microsoft fornisce sul portale ASP.NET.

Where have I gone wrong and how do people manage their SQL queries?

Utilizzo da anni i framework ORM che minimizzano la quantità di SQL che devo usare. Per i momenti in cui devo scrivere SQL (che non è spesso), mi assicuro di scrivere codice conforme agli standard che funzioni su tutti gli obiettivi del database, li incorporo nell'assembly in una cartella SQL e caricare il flusso di risorse per l'esecuzione. Personalmente, non scrivo mai le query SQL in linea.

Is it ok to duplicate SQL queries?

Direi che è un odore di codice, ma è perché considero qualsiasi duplicazione tale.

risposta data 12.03.2013 - 23:26

fonte

Leggi altre domande sui tag code-quality refactoring asp.net-mvc code-smell vb.net

Dove devo posizionare la mia interfaccia? Come deprecare correttamente i metodi in Java?

score 8 · Accepted Answer

Bene, prima di tutto, avrai molte domande perché ti aspetti che l'applicazione faccia un sacco di cose.

I database hanno un paio di cose che possono aiutare, ma puoi peggiorare le cose usandoli male.

Gli ORM sono uno strumento che ti aiuterà a scrivere le query per te. Ma avrai ancora molte domande se hai un sacco di lavoro nel database che deve essere fatto.

Successivamente, puoi usare Views per creare alcune delle cose principali che vorrai usare più volte. Le viste sono utili per le cose complesse che è necessario assicurarsi di avere gli stessi calcoli in più situazioni. Ad esempio, abbiamo delle opinioni che raccolgono tutti i dati da varie tabelle per i dati finanziari che garantiscono che tutti i dati finanziari siano basati sullo stesso insieme di business logic. Tuttavia, non utilizzare le viste per le viste delle chiamate.

Puoi utilizzare le stored procedure e quindi chiamarle in più punti. (Assicurati di averli messi nel controllo del codice, però, gli SP sono codice!)

Tuttavia, potresti dover imparare a convivere con il fatto che ci sia un sacco di codice. Il nostro database ha oltre un migliaio di stored procedure. Organizzarli per schema ha aiutato. Se il tuo database non ha schemi, aiuta l'organizzazione usando una convenzione di denominazione sistematica. In questo modo, tu sai che tutte le cose che riguardano la finanza hanno la parola finanza in esse e quelle relative agli utenti hanno utenti in esse. Questo ti aiuta a trovare quello che stai cercando quando è necessario riutilizzarlo.

Il riutilizzo del codice può essere una cosa meravigliosa, ma c'è un avvertimento molto strong quando si interrogano i database. Se le query sono leggermente diverse, allora devono essere due query separate anziché una che invia più dati di quelli richiesti dall'applicazione in quel momento. L'aggiunta di campi che non hai bisogno di interrogare per poterli utilizzare altrove può causare problemi di prestazioni orribili che sono molto difficili per correggere (ho appena trascorso diversi giorni a provare a mettere a punto un tale casino e ho finito per eliminare oltre 400 righe di SQL non necessario! Ho anche migliorato le prestazioni riducendo il tempo di esecuzione di oltre il 60%). Quindi non seguire questa strada solo per avere meno domande. Le query più specifiche sono generalmente migliori di quelle generali per le prestazioni del database.