Posted by Erland Sommarskog on 10/01/73 11:17

sk (shripathikamath@hotmail.com) writes:
>> In an RDBMS, design is at the schema level, not
>> table-by-table; that is a 1950's file system. Why did you use the
>> non-relational, proprietary sql_variant data type?
>
> I have no requirements to use anything but Microsoft SQL Server 2000
> and >. Ever, on this project. So the issue of portability does not
> arise. It is however, a very valid point if you point out that
> "sql_variant is evil" for other reasons, but portability is not a
> concern for me.
>
> Maybe I should have just posed the question in
> comp.databases.ms-sqlserver

Well, you did, but Joe Celko thinks he has a mission to fill here.
No, please don't ask me what that mission would be.

Anyway, from what I could guess from the table description, sql_variant
looks like a good choice to me.

If there are a whole bunch of parameters, and they are dynamcially
added all the time, you cannot have a column for everyone of them.
Instead it's better to have row for each of them. In previous versions
of SQL Server, you would then have a couple of value columns - one for
each data type. sql_variant makes it possible to have a single column.

What is a good thing is to define the attributes somewhere, and with
their definition also keep track of their data type. For an
attributes like temperature, you don't really want to find a
datetime value.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[Back to original message]