How cool are User Defined Data Types in SQL Server? [closed]

Answer 1

I do not use code-based UDTs because I don't think that the extra complexity warrants the advantages. I do use T-SQL UDTs because there's very little extra complexity so that the advantages are worth the effort. (Thanks go to Marc_s for pointing out that my original post was incomplete!)

Regarding Code-based UDTs

Think of it this way: if your project has a managed code component (your app) and a database component (SQL Server) what real advantage do you gain from defining managed code in the database? In my experience? None.

Deployment is more difficult because you'll have to add assemblies to your DB deployment and alter these assemblies, add files, etc. within SQL Server. You'll also have to turn on the CLR in SQL Server (not a big deal but no one's proven to me that this won't have a performance/memory penalty). In the end, you'll have exactly what you would have had if you had simply designed this into your application's code. There may be some performance enhancement but it really strikes me as a case of premature optimization - especially since I don't know if the overall performance suffers due to having the CLR on versus off.

Note: I'm assuming that you would be using SQL Server's CLR to define your types. HLGEM talks about SQL Server 2000 but I'm not familiar with 2000 and thought it only had UDFs and not UDTs in externally-defined dlls (but don't quote me...I really am not familiar with it!).

Regarding T-SQL UDTs

T_SQL UDTs can be defined in SQL alone (go to "Programmability | Types | User-defined Data Types" in SQL Server Management Studio). For standard UDTs I would in fact recommend that you master them. They are quite easy and can make your DDL more self-documenting and can enforce integrity constraints. For example, I define a "GenderType" (char(1), not nullable, holding "M" or "F") that ensures that only appropriate data is permitted in the Gender field.

UDTs are pretty easy overall but this article gives a pretty good example of how to take it to the next level by defining a Rule to constrain the data permitted in your UDT.

When I originally answered this question I was fixed on the idea of complex, code-defined types (smacks palm to forehead). So...thanks Marc.

Answer 2

Never use them is my advice. You are in a world of hurt if you ever have to change the definition. Perhaps this has improved since SQL Server 2000 and someone with more familiarity with the newer versions can tell you whether it is now safe to get in the water, but until I had confirmation of this and had checked it out myself with a test, I wouldn't put it on my production system.

Check out this question for details: How to change the base type of a UDT in Sql Server 2005?

Answer 3

The pro of user defined types is addressed quite well by Alex Papadimoulis. The cons have been well stated here.

I would also like to point out that the sp_bindrule function has been deprecated, as noted by Alex's post. I'm not sure when it was deprecated but it is now. In fact, rules are deprecated as a whole.

Were I to want to create a type with a restriction, I'd consider using a user defined table type with a check constraint on the appropriate column(s). This also gives me a way of building a complex data type.

Answer 4

I can't really recommend the use of any sql-implementation specific features that make it harder when you are growing out of mssql and are migrating to another dbms. For our dwh dbs we started on mssql, migrated to oracle and have since last year graduated to hp vertica.