Yukon and User Defined Types (UDTs)

In response to Sahil Malik's recent post on CLR Types as UDT's in Yukon, I have to say I prefer the Typed Xml in Yukon to CLR Types. 

In Yukon there are two paths to creating User Defined Types.  The CLR path has some limitations, (primarily the 8K size limititation).  I am a big fan of the XML Type path.  Typed XML inside the server is a better way to create complex types in the database IMHO.  Typed XML is schema based.  This means the types in your database can be exposed externally as well if needed (like through web services <some of you might be seeing a pattern emerge here>).

In addition, Microsoft's extensions to XQuery (which I hope the standards board adopt) allow you to do in-place editing of Typed XML which means you don't have to do wholesale replacement of xml documents any longer (or wholesale changes to CLR based UDF's).  The syntax allows you to do insert, updates and deletes to individual nodes (or series' of nodes).

 

Comments:

Gravatar

LOL MAN this is funny .. I'm still working on a series of about 4-5 posts .. and I'm getting comments on my blog already .. !!

Allright, I'm gonna post a red banner on top that says "WORK IN PROGRESS - HOLD UR COMMENTS".

Sahil Malik (Posted Thursday, February 03, 2005 )

Gravatar

But I like your comment .. !! Makes me go .. Hmmmmm !!!

Sahil Malik (Posted Thursday, February 03, 2005 )

Gravatar

Now that I have some time to breathe, let me point out a few things Typed XML cannot do, and UDTs can. (I might be wrong, and hopefully I'll learn from you).

Typed XML is unable to store logic/validation inside as CLR code can. You cannot embellish typed xml data types and create code like this --

Select Min(CoOrdinate.DistanceFrom(2,3)) from MyTable.

Second disadvantage lies in performance and indexing.

UDTs aren't kickass performance but XML could be worse. UDTs atleast give you enough control over indexes and the ability to implement IBinarySerialize in UserDefined formats (or native even), thus shuffling bytestreams around to read using a BinaryReader. Not to mention, index sizes for Xml data types are complete pigs as far as their sizes go, and XQuery based queries on larger tables would run reaaalllyy slow .. if it weren't for those larger indexes.

I think both serve a purpose and I'd hate to loose either.

But I will say - I'd be careful before using either of the two.

(I bludy hope I didn't misunderstand what you meant by "Typed XML" in Yukon LOL).

Sahil Malik (Posted Friday, February 04, 2005 )

Gravatar

Here's the largest point. The database is no place for business logic. If you're talking about validation logic, .xsd supports that already.

Shawn Wildermuth (Posted Friday, February 04, 2005 )

Gravatar

While I agree in theory, and that is why you are not going to give up T-SQL just because you can write stored procs in .NET CLR; .... the whole argument behind .NET CLR stored procs are - you can now do certain things which SQL wasn't good at; especially mathematical calculations.

Is that business logic? .. well maybe it is .. but where's the fine line and when did we cross it? :)

Sahil Malik (Posted Friday, February 04, 2005 )

Gravatar

Remember that CLR Types are not an argument for or against using the CLR inside Yukon. Doing programming that is hard in T-SQL is a justification for using CLR UDF's, not UDT's IMHO. And Managed stored procedures make sense when you have to have logic that is difficult in T-SQL. So we're on the same page there.

Shawn Wildermuth (Posted Friday, February 04, 2005 )

Gravatar

I respectfully disagree. Comparing a CLR UDT type to an XML type is the proverbial comparison of apples and oranges. CLR UDTs are small scalar types with behavior. They are not meant to be large, complex types, for which the XML type is better suited.

Peter DeBetta (Posted Tuesday, May 03, 2005 )


 



 
Save Cancel