quote:
Frankly if your schema is in a regular state of flux and you are not in a development environment then there is something seriously wrong with the design or analysis behind the database. Possibly the DBA has been given the title because it is one he can spell!
Some companies/industries have neither the luxury of semi-static schemas, nor the privelege of being able to ignore customer requirements - requirements that change, and change often. Say you make a UDT for a serial number, say CHAR(12) NOT NULL, and then 2 months down the road, you take on a customer that has 13-digit serial numbers. You might say, well, why didn't you just make the field a VARCHAR(20) to start with? a) Don't always have the choice (see scorpion's comments above), and b) What about 25 or 30 characters long? Sometimes there isn't a way to know all the details up front...
Having UDTs is, I believe by design, inflexible. Changing the underlying datatype of a UDT is a sever PITA (see below), and doesn't grant a DBA, or a programmer for that matter, any more benefit than an Excel spreadsheet with a list of commonly used business data types. Until the ability to *easily* change an underlying datatype is given, UDTs will go largely by the wayside.
As for ty_Today and ty_Yes, I say, isn't that going a bit far???
quote:
You need scripts:-
- To propogate any new types.
- To drop any indices on the columns being changed.
- To drop any DRI using the columns.
- To apply your extra UDTs or refresh the old ones within the table
- To recreate indices
- To reinstigate DRI
In other words bread and butter DBA stuff.
In other words, boring, tedious tasks that should be programmed into the SQL Server environment by MS in the next release (see comments above by ckempste). Bread and butter, maybe, but for those of us who don't have the time to spend scripting up such tedium, an automated tool would allow for time to be spent on (much) more important things.
Another note: ckempste's point c) cannot be stressed enough.