I want to further validate comments made by a number of people. For demo purposes, this works fine, but it is a bad example of a real-world UDT. This point needs to be made very clear in the article, and it is not. It is even implied that this is a good real-world use, as shown here:
"The physical stock and system stock are stored separately in two different columns. Why do we not have a single column for this purpose? This thought came up as soon as I saw my own design."
This is not a reason for creating a UDT. The purpose of UDTs is to extend the type system, not combine existing types into a more complex type. It was also stated that:
"...this little scenario is going to be used for our first UDT, though a little simple."
Making a more complex type to represent 2 perfectly good types already in the relational design does not simplify, but rather, complicates the database design. Issues arise, such as querying against system stock. Based on the implementation, this would not be doable with any efficiency since the native serialization would serialize the physical stock first. The only way to efficiently query against the system stock value is to now create a computed column of the system stock and then index that computed column, which defeats the stated purpose of creating this UDT in the first place.
Don't get me wrong, I think CLR integration is a great feature, but must be used with prudence.