I am starting a new project, and I am considering using alias data types in my SQL Server 2005 database, for common table columns. For e.g. I would define an alias data type to hold the name of an object, as follows:
CREATE TYPE adt_Name FROM
varchar(100) not null
Then use it for the definition of table columns, ensuring all my columns share the exact same definition (length, nullability, precision, etc).
- What are the advantages of using alias data types?
- What are the disadvantages of using alias data types?
- What naming conventions would you recommend? I was thinking adt_Xxx (adt = alias data type).
- Why does SQL Server 2005 Management Studio not allow me to work with alias data types from the GUI. I can only use them through SQL Scripts. The GUI doesn’t list them in any of the drop-down boxes – its frustrating.
- How will the use of alias data types affect my Linq to SQL model?
Advantages:
Reusable and Sharable, the ADT is reusable within the database it’s created in, if you want it across all your DBs then create it in the model database
Enforcement, the ADT will enforce the characteristics, length and nullability of it’s base type, and can be used to enforce development standards
Disallows implicit conversions, ADTs cannot be CAST or CONVERTed
Simplicity, as with other languages, ADTs lend simplicity to development and maintenance
Data Hiding
Disadvantages:
Unmodifiable, ADTs cannot be directly modified, you must DROP and reCREATE them. Note that you can still ALTER the tables they’re in to another base type or ADT, then DROP and reCREATE them, then ALTER the tables back (or just CREATE a new one to alter them to).
No Tools, ADTs must be created with a direct query using the CREATE statement (sp_addtype is deprecated and shouldn’t be used).
Table variables are not supported
Naming Conventions:
Linq to SQL: