is creating db user defined data types best practice?

Question

Is creating user defined types instead of using existing types best practice? In my previews work place all basic types were predefined, is it best practice? what advantages and what disadvantage it has.
Thanks a lot!

Answer 1

In MS SQL Server - the idea is great. However, there's a BIG but to them: you can't change them once they're in use, since there's no ALTER TYPE .... statement. This can be a major hassle.

Consider this: you have a bookstore app which has a user-defined type ISBN = VARCHAR(10) - works like a charm. Now the international committee decided to increate the ISBN field to 13 characters - unfortunately, there's no ALTER TYPE ISBNType..... so your only choice is to basically drop all the columns of that type in all of your database, then re-create the type in its new form, and re-create all those columns again.

The idea is great and I would love to use it - but in its current state, it's next to unusable, in my opinion, which is unfortunate.

Marc

Answer 2

A bit late, but.. my 2 cts.

The user defined types fulfill the role of a domain in the conceptual and logical models, so if you want to implement your logical datamodel in the physical database, the use of user defined types would be the closest approximation. This will provide benefits such as using a graphical model that can be transferred to an implementation automatically, better than it could be done without using UDTs.

Using domains makes it possible to detect attempts to store a postal code in an SSN field and have them caught by the database at run time (or even compile time). This will enable you to enforce company wide business rules where they should be enforced: at the point where the data hits the storage. Anywhere else is a courtesy to the user, but this is where they absolutely HAVE to be enforced to make sure noone goes around them.

Also, UDTs as defined in ANSI SQL:1999 encapsulate methods, and can be subtyped. That means that certain changes in business rules that deal with constraints can be changed in the database, without ever having to touch an implementation.

However... as currently implemented UDTs leave a lot to be desired. I'm not even sure SQL Server implements the standard as described, even less sure about Oracle. And even if they do, the disadvantages of using UDTs will become obvious right away as you use BI tooling, ETL tooling or other rather simple-minded tools: they don't usually understand UDTs and even if they do, they won't be able to use them because the majority base themselves on basic types (int, char and date/time).

As for reporting tools, let's consider a UDT that has a combination of fields. Now, how would a database-agnostic ETL-tool be able to understand the type? It would have to be able to understand the structure in order to display it, or use it for calculations. And that for every supported database - a difficult task. And since noone uses UDTs, they won't do this. It's a vicious circle, but we still have to live with it.

Apart from that, UDT support in most databases isn't all that hot either. Changing types can be quite hard. While the syntax should be the same everywhere, their administration is undefined in SQL:1999 and therefore different everywhere. Try changing the owner of a UDT in sql server for an example. That used to be pretty difficult - not sure about SQL Server 2016, but given that UDTs don't look like a focus area, I'm not expecting major improvements in that area.

Lastly, if you add really complex code to UDTs, you run into the old problem that you are programming in an environment that has a lack of good debugging options. That doesn't help either.

So: if you have full control over your database and all interaction goes through your software, UDTs can be extremely helpful. If not, they can be a huge pain the neck. Which one is the case in your scenario, is something only you can tell.

Answer 3

How cool are User Defined Data Types in MS SQL Server?

Personally, I don't use them but I've seen them. One problem is that client code recognises the base type only, IIRC, for MS SQL Server at least. And portability/behaviours across versions.