10 reasons to explicitly convert SQL Server data types
As a general rule, you should avoid using SQL Server’s sql_variant
data type. Besides being a memory hog, sql_variant is limited:
- Variants can’t be part of a primary or foreign key. (this doesn’t hold as of SQL Server 2005. See update below)
- Variants can’t be part of a computed column.
- Variants won’t work with LIKE in a WHERE clause.
- OLE DB and ODBC providers automatically convert variants to nvarchar(4000) — ouch!
To avoid problems, always explicitly convert sql_variant data types as
you use them. Use any method you please, just don’t try to work with
an unconverted sql_variant data type.
I haven’t used sql_variant
before but with these restrictions and performance implications in mind, I would first look at alternatives.
Following would be my most to least prefered solution
- Simply create three different columns. 3 Different data types (should) mean 3 different ways of interpreting it both at the client side and server side.
- If that is not an option, use a
VARCHAR
column so you can at least useLIKE
statements. - Use the
sql_variant
data type.
Edit Cudo’s to ta.speot.is
Variants can be part of a primary of foreign key
A unique, primary, or foreign key may include columns of type
sql_variant, but the total length of the data values that make up the
key of a specific row should not be more than the maximum length of an
index. This is 900 bytes