Qual è stata la tua esperienza con SQL CLR per la logica aziendale complessa?

L'integrazione SQL CLR è stata sviluppata principalmente perché l'implementazione della logica tramite T-SQL era davvero difficile. .NET Framework se riempito con migliaia di librerie utili, a cui non si ha accesso a livello di motore SQL. Pertanto, qualsiasi logica dovrebbe essere implementata da zero. Ad esempio, un semplice ciclo foreach dovrebbe essere implementato con cursori, che sono onestamente molto meno produttivi.

Ho esperienza di lavoro con l'integrazione di SQL CRL. L'ho fatto per la conversione data-ora a livello di motore di database. La conversione di data e ora a livello di motore di database è davvero molto difficile, mentre .NET, ha System.Globalization che facilita il lavoro.

Il punto principale di questo metodo è seguire il passo esattamente come descritto (come i metodi di estensione in cui i metodi dovrebbero essere funzioni statiche all'interno di classi statiche all'interno di namespace di primo livello). Se non riesci a fare qualcosa esattamente come ti è stato detto, le cose semplicemente falliscono.

Ho usato procs e trigger SQL Clr con effetti molto buoni per aiutare le prestazioni del database in alcuni casi. Ci sono situazioni in cui la tua logica TSQL sta andando a funzionare lentamente (ricerca full text senza indici FTS), e ci sono alcune cose che non puoi fare in TSQL (cercare un indirizzo DNS, ridurre la mappa, elaborare immagini, OCR, decomprimere un file, algoritmi complessi, ecc.)

I'm considering it because I have to look at some data, run it through a bunch of procedural logic, update, and then get it back to the client. My thinking here is to get as close to the DB metal as possible, and use that hardware to make it happen quickly

Ma quello non è uno scenario in cui consiglierei di usarli. L'altro poster è corretto che la teoria degli insiemi ha quasi sempre un modo per fare quello che vuoi.

SQL CLR non è più vicino al metal, stai eseguendo un'istanza completa di .net clr all'interno del tuo database. Se non ne hai nessuno in questo momento, aggiungendo uno si aggiungerà un sacco di RAM per quel processo. Se hai 20, allora il costo non è così male "per proc".

Se stai cercando di fare tutti questi calc per riportare i dati al client, fallo sul client. Il client di solito ha a disposizione quasi il 100% della CPU. Il server non sarà mai vicino a quello per un utente.

Se hai una vera logica centrale o requisiti aziendali complessi che non vuoi mettere su tutti i client, mettila sul server. Non eseguire semplici operazioni CRUD in SQL Clr, non ti compra di solito.

È meglio usare CLR di t-SQL se è una logica complicata. Prenderò in considerazione questo approccio solo usando il codice dell'applicazione a patto che tu lo consideri:

1. È necessario / preferire condividere questa funzionalità con più applicazioni che utilizzano il database e non sono in grado di condividere il proprio codice interno.
2. Il database ha molte risorse disponibili per effettuare i calcoli.

Il codice di condivisione è ottimo, ma non a discapito delle prestazioni del tuo database.

In primo luogo, cerca molto duramente di non usarlo - mentre ho implementato sia una stored procedure CLR che una funzione di tabella vettoriale in streaming, entrambi hanno avuto problemi, soprattutto nelle prestazioni.

Il mio sproc fondamentalmente bombardato quando presentato con un milione di file di dati, mentre una procedura sql che chiamava una funzione scalare (in CLR - nel mio caso forniva una funzione regex) funzionava, e funzionava molto più velocemente di quanto lo sproc non . SVTF aveva alcuni problemi di sicurezza tali da poter funzionare solo su un DB di sviluppo per sviluppatori (ci piace la sicurezza presso la nostra sede), quindi è stato eliminato. Le prestazioni erano ugualmente cattive ma non così male come lo sproc.

Quindi attenersi a semplici funzioni scalari, ma cerca di non usarle molto e mantenerle molto semplici.