"Currently, UDDTs don't support the notion of subtyping or inheritance, nor do they allow a DEFAULT value or CHECK constraint to be declared as part of the UDDT itself. These powerful object-oriented concepts will likely make their way into future versions of SQL Server. These limitations not withstanding, UDDT functionality is a dynamic and often underused feature of SQL Server."
There's no point bothering with using a UDDT in T-SQL if you can't apply constraints to the UDDT!
1 vote for the introduction of the mentioned features into T-SQL
comments anyone?
Hi Kevin your link references SQL 7.0, which is almost 10 years old :) Much of this can be accomplished in SQL 2005.
|||Ah, my bad.Sorry I'm having a lot of trouble finding quality information on how to use a UDDT as a domain in T-SQL. I thought the above was why, instead it must have been my inability to search properly.
I just found the concept applying a RULE to a UDDT which should help...
Thanks Greg, at least now I know I should keep looking.
|||
T-SQL UDTs still lack this functionality, and rules are being depricated and won't be around very long.
If you are willing to use the CLR, the sky is the limit, but it is not altogether easy or straightforward how to use them. Start with the 2005 books online, under UDTs [CLR integration].
|||I have been trying to avoid CLR UDTs for the simple tasks I'm doing. But you're right they are powerful. I'm simply struggling to let go of SQL domains for the sole purpose of not having to rewrite a few constraints.|||Hey, I don't blame you. They have some cool power, but a bit too much complexity for my taste. I do hope they give us easier to use domain support in the future, but not yet :)
No comments:
Post a Comment