SQL CLR: un aiutino per velocizzare le applicazioni

Capita molto spesso che un vecchio applicativo abbia bisogno di manutenzione per motivi di performance.
Un esempio? Il classico gestionale sviluppato in VB o ASP-classic.
Di questo programma, consideriamo una singola funzione: la ricerca avanzata sugli ordini, che valuta ogni ordine secondo le piu' svariate condizioni.
Alcune di queste condizioni possono essere valutate direttamente via SQL, quindi sara' possibile scaricare parte della elaborazione su SQL Server a beneficio della nostra applicazione.
Ci sono condizioni che dobbiamo giocoforza valutare via codice, perche' riscrivere la stessa logica in T-SQL sarebbe anti-economico.

Spendiamo tempo per duplicare queste funzionalita' in SQL-Server e migliorare le performance ?
Oppure ci accontentiamo di avere performance povere ?

Con un piccolo investimento e' possibile salvare capra e cavoli.

SQL Server 2005 ha un modulo utilissimo che fa proprio al nostro caso: SQL CLR.
SQL CLR ci permette di importare assembly .NET in SQL Server e, tramite delle apposite store procedure, da T-SQL sara' possibile utilizzare le funzioni sviluppate in .NET.

Per operare con SQL CLR ci sono poche e semplici operazioni da fare.
Innanzitutto verificare se il nostro database ha SQL CLR abilitato.

EXEC sp_configure @configname = 'Show Advanced Options', @configvalue = 1
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure

Cercate la voce "clr enabled" e valutate il valore della colonna "run_value": se "1" allora SQL CLR e' abilitato, in caso diverso non lo e'.
Per abilitare SQL CLR si procede nel seguente modo:

EXEC sp_configure @configname = 'clr enabled', @configvalue = 1
RECONFIGURE WITH OVERRIDE
GO

Ora che SQL CLR e' attivo, bisogna importare l'assembly .NET delle nostre funzioni in SQL Server.

CREATE ASSEMBLY OrdersConditionsAssembly
FROM 'C:\OrdersConditions.dll'
 WITH PERMISSION_SET = SAFE
GO

Ora dobbiamo creare una store procedure che funga da wrapper per le funzioni presenti nell'assembly.

CREATE PROC sp_OrdersConditionABC
 @OrderID NVARCHAR(255)
 AS EXTERNAL NAME OrdersConditionsAssembly.[MyNamespace.MyClass].ConditionABC
GO

Il percorso per definire la classe (namespace e classname) viene racchiuso tra [] per protezione, in quanto SQL Server non accetterebbe i "." all'interno.
Se la classe non fosse definita in un namespace, il percorso sarebbe composto del solo classname e quindi delle []; il percorso dell'assembly sopra definito diventerebbe: OrdersConditionsAssembly.MyClass.ConditionABC .

In funzione delle nostre esigenze, oltre alle store procedure, si possono creare delle function

CREATE FUNCTION [dbo].[f_OrdersConditionDEF] (@OrderID nvarchar(255))
 RETURNS bigint
 AS EXTERNAL NAME [OrdersConditionsAssembly].[MyNamespace.MyClass].[ConditionDEF];
GO

Un aiuto viene da Visual Studio 2005, perche' all'interno di un database, e' possibile definire con facilita' le store procedure:

L'invocazione di queste store procedure e function, non e' differente dal resto delle store e function ed avviene come di consueto.

Ecco alcuni esempi:

DECLARE @Message NVARCHAR(255)
SET @OrderID = '200712345abcdef'
EXEC sp_OrdersConditionABC @OrderID

oppure

SELECT *
FROM ORDERS
WHERE f_OrdersConditionDEF(ORDERID) > 100

Ora, il punto cruciale rimane la traduzione da ASP/VB/etc a codice .NET, ma questo e' il vostro piccolo investimento.

Commenti