Best Practices for embedding .NET assemblies in SQL Server

Question

What are some important practices to follow when creating a .NET assembly that is going to be embedded to SQL Server 2005?

I am brand new to this, and I've found that there are significant method attributes like:

[SqlFunction(FillRowMethodName = "FillRow", TableDefinition = "letter nchar(1)")]

I'm also looking for common pitfalls to avoid, etc.

Answer 1

Some that I remember:

• Keep its usage to a minimum, only use it when T-SQL proved too complex.
• Avoid pointers/cursors at all costs because a for loop is so easily abusable in CLR context.
• Only use the SQL-Server native data types unless totally necessary.

Can't remember where I've found the information, but those are some that I do remember.

Basically, only use it when declarative T-SQL is too complex or is impossible to do (such as registry editing etc.).

Answer 2

Single tip regarding assembly deployment:

Keep functionality isolated across small assemblies. Try not to build a dependency chain, because replacing a base assembly means you need to remove the dependent assemblies first, before you can update the base assembly.

Answer 3

I would strongly advise against putting .net assemblies in your database server, think n-tier applications. Persistence <- Business Logic <-Presentation Logic <- client Keep your Logic in your Business Logic layer.

The only reason I can think of to put .net in your database would to add a new complex data type, I would strongly that this be a dumb class that only holds data and does no processing on it.

Just because you can does not mean you should. Sorry for not directly answering your question.