Uso appropriato di SQL CLR

Naviga le tue risposte
4

Abbiamo alcuni processi back-end che vengono eseguiti * sul nostro server SQL (SQL Server), che implicano l'elaborazione delle attestazioni. Ciò richiede sia la manipolazione dei dati (biz logic) che i dati di lettura / scrittura sulle tabelle. La logica biz contenuta non dovrebbe mai essere utilizzata da nessuna delle applicazioni dell'utente finale (web / fat client), solo per questo (viene eseguito una volta, ogni notte).

* Per "corre" intendo che funziona, ma è lento, pieno o errori, ed è un incubo da mantenere, stiamo cercando di rifare questo per risolvere questi problemi.

Una cosa che sto cercando di evitare è la scrittura di una Stored Proc a 3000+ linee (ne abbiamo alcune) che fa tutto, non è mantenibile.

Il mio approccio / approccio iniziale è:

  • SQL CLR (Sql 2012 / C # .Net 4.0) per la logica biz (ci sarà un po 'di complessità nella logica)
  • Entity Framework per qualsiasi semplice lettura / scrittura CRUD
  • Procedure memorizzate per qualsiasi lettura / scrittura di dati complessi.

Ci sarà un'ultima fase di scrittura dei nostri risultati finali (dati) in altri database aziendali, ma questa è un'altra responsabilità di qualcun altro.

Vorrei qualche riflessione su questo approccio se è buono (c'è un approccio migliore?), qualsiasi suggerimento sarebbe apprezzato.

    
posta Chris L 23.08.2012 - 18:38
fonte

3 risposte

4

Dal momento che non è necessario eseguire questo "in" SQL Server e non è necessario riutilizzare alcun codice in nessun altro punto in SQL Server, creare un'altra applicazione server nella lingua prescelta e attivarla da un programmatore. Questo potrebbe darti la possibilità di scaricare il numero crunch su un altro server. L'utilizzo dei proc memorizzati è ancora un'opzione se ne hai bisogno.

Potrebbe non essere abilitato CLR, quindi perché preoccuparsi solo di questo?

    
risposta data 23.08.2012 - 19:56
fonte
2

Personalmente, preferisco usare solo sp quando il processo è solo a livello di database, ad es. popolando alcune tabelle in base ai valori di altre tabelle, ad esempio facendo aggiornamenti mensili dei dati, ecc. Se per nessun altro motivo, è difficile (almeno nella mia esperienza) fare correttamente la versione SP, quindi mi piace escludere qualsiasi logica di business dal database se possibile.

    
risposta data 23.08.2012 - 20:36
fonte
0

Se il processo può essere completato nel database, attenersi alle procedure memorizzate poiché queste dovrebbero funzionare al meglio.

Hai ragione nel cercare di evitare una procedura che contiene molte righe di codice. Se questo è il caso, dividere la procedura in un numero di procedure più piccole. Tra questi possono esserci elementi comuni, quindi è possibile introdurre il riutilizzo con l'uso di variabili passate alle proprie procedure. Il modo in cui li chiami dipende dal design del sistema: potresti aver bisogno di un livello aziendale nell'applicazione o di una procedura memorizzata master per farlo.

    
risposta data 23.08.2012 - 23:50
fonte

Leggi altre domande sui tag

perché javascript è un linguaggio di scripting ampiamente utilizzato nelle applicazioni web? [duplicare] Perché gli errori di nesting o piggybacking all'interno degli errori sono in generale cattivi?