Una procedura memorizzata di SQL Server CLR che chiama un'API Web ASP.NET

Ho lavorato in luoghi dove gli assemblaggi CLR sono usati in questo modo. Secondo me è una cattiva idea.

Ecco il mio ragionamento.

1: l'incorporamento della logica nel database è sempre negativo. Questa è una posizione di "filosofia di programmazione", ma ritengo che sia giustificata come regola generale

2: CLR sarà limitato a .net 2 sul server mssql

3: Il CLR può scadere o un errore a causa della sua dipendenza dalla risorsa esterna. Questo produrrà diversi set di risultati dallo sproc

4: il DB seleziona? quindi chiamare l'API che poi inserisce ti darà problemi di blocco e di transazione senza soluzione facile

5: hai già un layer .Net nella tua soluzione (il webapi) in modo da avere l'infrastruttura per supportare un servizio Windows o un'applicazione simile che possa adempiere al ruolo aziendale.

Immagino che la cosa che manca alla tua domanda che mi consentirà di suggerire un modello migliore è ciò che sta chiamando lo sproc in primo luogo?

Solo una rapida espansione sul punto 1 perché so che può essere polemico. Ho lavorato in molte aziende e tendo a vedere due tipi di sistemi.

Sistemi inizialmente creati dagli amministratori di database. questi tendono ad avere un sacco di lavori di SQL Agent, grandi sproc con case statement, loop e business logic, pacchetti SSIS ecc.

Sistemi inizialmente creati dai programmatori. Questi tendono ad avere indici o chiavi, colonne xml, ecc. DB appena usato per la persistenza degli oggetti

Il DBA ha creato dei sistemi che cadono perché non scalano

I sistemi di programmatori ottengono dati corrotti ma non riescono a resistere. Perché puoi sempre aggiungere un'altra casella web

Sulla base della risposta di Ewan, posso proporre un modo per fare il tuo lavoro senza usare CLR:

1) Si crea un lavoro (servizio Windows, applicazione eseguita da un'attività pianificata, ecc.) che verifica se sono richiesti dati aggiuntivi

2) Recupera i dati dal lavoro chiamando il Web.API

3) Esegui la tua elaborazione nel lavoro. Se la logica è complessa, C # è molto meglio di SQL

4) Persistere i dati dal lavoro. La persistenza può essere eseguita utilizzando BulkInsert per prestazioni migliori.

I linguaggi di alto livello come C ++, C #, Java sono quasi sempre più adatti per la definizione della logica di business. Funzionano molto meglio in casi iterativi, consentono OOP, registrazione avanzata, gestione delle eccezioni, debugging ecc.

Se la migrazione della stored procedure non è un'opzione, puoi comunque svolgere il tuo lavoro:

3) persistono i dati recuperati in alcune tabelle buffer che hanno un identificatore di sessione di elaborazione. Se il volume di dati recuperato è elevato, l'inserimento collettivo è tuo amico

4) chiamare la procedura utilizzando l'identificativo della sessione di elaborazione. La procedura riceverà i dati dalle tue tabelle buffer

5) se il volume dei dati è molto alto, è possibile svuotare (troncare) le tabelle del buffer durante un periodo di utilizzo ridotto, in quanto le eliminazioni hanno un grande impatto sulle prestazioni