Pros and Cons with (non CLR) UDTs in SQL Server

  • Hello all,

    I was just entertaining a UDT discussion (it's right or not to exist in SQL Server) with a friend of mine and I would like to hear your opinions.

    I, for my self, like UDTs since they encourage the use of a data dictionary and conforms types and (hopefully), column names. This in itself removes unnecessary bugs created from implicitly casting the types in different ways when comparing and the potential performance gains you could have, if, in your system you have many (mistakenly introduced) int=smallint comparisons.

    Regards,

    Hanslindgren

  • I personally would avoid them like the plague!  It could be useful to define a postcode data type ( in the UK ) as a char(8) but I remain unconvinced.

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]
    www.grumpyolddba.co.uk
    http://sqlblogcasts.com/blogs/grumpyolddba/

  • The are effectively a point-in-time template, so although you define a user-defined datatype for a non-nullable integer with a default of 1 this only applies when you create the column based on that UDT.

    If you amend the UDT the change does not propogate through your database. This should not be an issue if your data design is fairly static but if you get a situation where someone defines (for example) a telephone number field then decides that it is too small, then decides to include the international prefix, then decides to append the extension number etc it becomes a bit pointless.

  • Yes.  But since you cannot ALTER types and you cannot DROP them if they are referenced I think it must be a little bit hard to change them frequently.

    Having just started out a new job with a database that is quite messy caused by loads of developers, a high turnover rate and what seems to be a lack of common direction. Ex. columns containing the same type of data but defined different (VARCHAR vs NVARCHAR, length 50 vs 250, NULL vs NOT NULL and often names that indicates different data). Having UDTs I guess would force at least a third or fourth thought before defining a new column.

    Another thing is that the DBs are quite complicated (probable cause proposed above) and some developers (for checking dependencies and related columns) are doing searches on the column names in syscomments or syscolumns. Having UDTs would at least make their searches easier by the use of 'xusertype' column.

    P.S I am not talking about CLR UDT but good old fashioned SQL Server 2000 UDTs (which MS now cleverly have started denominating 'Alias Data Types'.

    Regards,

    Hanslindgren

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply