What types of objects are useful in SQL CLR?

I’ve had a number of people over the years ask about whether or not a particular type of object is a good candidate for SQL CLR integration. The rules that I normally apply are as follows:

Database Object

Transact-SQL

Managed Code

Scalar UDF

Generally poor performance

Good option when limited or no data-access

Table-valued UDF

Good option if data-related

Good option when limited or no data-access

Stored Procedure

Good option

Good option when external access is required or limited data access

DML Trigger

Good option

Rarely a good option as most perform substantial data access

DDL Trigger

OK option if only limited processing of XML EVENTDATA

Good option for extensive processing of XML EVENTDATA

Aggregate

Not possible

Good option

User-defined Data Type

Only alias types

Good option

 Scalar UDFs written in Transact-SQL are well-known for causing performance problems in SQL Server environments. Managed code is often a good option (and generally a much faster option) for implementing scalar UDFs as long as the functions do not depend on heavy data access.Table-valued Functions that are data-oriented are likely to be best implemented in Transact-SQL. A common use case for managed code in table-valued UDFs is for functions that need to access external resources such as the file system, environment variables, registry, etc.

 

Stored procedures have traditionally been written in T-SQL. Most stored procedures should continue to be written in T-SQL.  There are very few good use cases for managed code in stored procedures. The exceptions to this are stored procedures that need to access external resources or perform complex calculations. There should be consideration, however, about whether code that performs these tasks should be implemented within SQL Server at all.

 

Almost all DML triggers are heavily-oriented towards data access and are written in T-SQL. There are very few valid use cases for implementing DML triggers in managed code.

 

DDL triggers are also often data-oriented. Some DDL triggers though need to do extensive XML processing, particularly based on the XML EVENTDATA structure passed to these triggers by SQL Server. The more that extensive XML processing is required, the more likely the DDL trigger would be best implemented in managed code. Managed code would also be a better option if the DDL trigger needed to access external resources but this is rarely a good idea within any form of trigger.

 

Transact-SQL offers no concept of user-defined aggregates. These need to be implemented in managed code. A common use case for user-defined aggregates is to create functionality that exists in other database engines while migrating to SQL Server. For example, if a database engine provides a RANGE function, a replacement could be written in managed code to avoid the need to rewrite the application code. As a further example, the SQL Server Migration Assistant uses managed code to ease Oracle migration. SQL Server 2005 limited user-defined aggregates to those that could be serialized in 8KB of data. SQL Server 2008 changed this limit to 2GB and also introduced the ability to create multi-column aggregates.

 

Transact-SQL offers the ability to create alias data types but these are not really new data types. They are more like subsets (or subclasses) of existing built-in data types. Managed code offers the ability to create entirely new data types and determine not only what data needs to be stored but also the behavior of the data type. It is important to understand however that the intention of user-defined CLR data types is not to convert SQL Server into an object-oriented database. Data types should relate to storage of basic data, not to objects such as employees or customers.

Should vendors have an express queue for people who have a clue? What passes for support today?

It’s good to see some airports that have queues for people that travel frequently and know what they’re doing. But I’m left thinking that IT vendors need to have something similar.

Bigpond (part of Telstra) in Australia have recently introduced new 42MB/sec modems on their 3G network. It’s actually just a pair of 21MB/sec modems linked together but the idea is cute. Around most of the country, they work pretty well. In the middle of the CBD in Melbourne however, at present they just don’t work.

Having more patience than myself, my wife (who also has one) called their support line today. The symptoms were:

  • The data connection works fine till around 8AM. 
  • It works fine again after about 5:30PM.
  • At all other times during the day, the connection strength shows a full signal and connections happen instantaneously.
  • During the day, a ping to the default gateway is returned after about 3 seconds about 1 in 100 times. All other pings are lost.
  • No DNS names can be resolved at all.
  • No IP traffic can move at all.

Now, let’s see what you think about the suggestions from the “support” people:

  • It must be a problem with your computer configuration. (Interesting that it works fine outside those times without change)
  • It could be a problem with your browser cache. Please clear it. (Hmmm, well there goes the useful cache)
  • It might be a problem with your username and password. (But how does it work without change the rest of the day?)
  • Please manually connect to the Telstra 3G network instead of the Telstra network that we connect you to by default. (No change occurs)

And then they get scary:

  • Please reset all the security zones for all sites in your browser. That might be the problem. (WTF???? What outstanding advice!)

At what point do companies ever begin to think that this sort of nonsense is acceptable?

Do you have different levels of support for your customers, depending upon their knowledge level? If so, how do you decide who can use the more advanced support? How do you control access to it?

Slow in the Application but Fast in SQL Server Management Studio – from Erland

Our MVP buddy Erland Sommarskog doesn’t post articles that often but when he does, you should read them. His latest post is here:

http://www.sommarskog.se/query-plan-mysteries.html 

It talks about why a query might be slow when sent from an application but fast when you execute it in SSMS. But it covers way more than that. There is a great deal of good info on how queries are executed and query plans generated.

Highly recommended!