使用 SQL Server 2005 SP4，我正在设计一个数据库表。
这是表 DDL
CREATE TABLE CPSync4D.ProjectProfilerOption
(
ProjectProfilerOptionID INT IDENTITY(1,1) CONSTRAINT PK_ProjectProfilerOption_ProjectProfilerOptionID PRIMARY KEY
,ProjectID INT CONSTRAINT FK_ProjectProfilerOption_Project_ProjectID FOREIGN KEY(ProjectID) REFERENCES CPSync4D.Project(ProjectID) ON DELETE CASCADE
,ProfilerOptionID TINYINT CONSTRAINT FK_ProjectProfilerOption_ProfilerOption_ProfilerOptionID FOREIGN KEY(ProfilerOptionID) REFERENCES CPSync4D.ProfilerOption (ProfilerOptionID)
,ProfilerOptionValue sql_variant NOT NULL
)
Go
profileroptionvalue 列可以保存最多 30 个字符的字符串、整数或小数值，例如值为“ProfilerValueType”，或12.52或20等(不超过两位小数且整数值小于100)
我应该使用 sql_variant 还是 varchar(30)...？我以前从未使用过 sql_variant，并且不确定不使用对数据库设计有何影响。
在 .net 代码中使用 sql_variant 的任何陷阱
最佳答案
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.
我之前没有使用过 sql_variant，但考虑到这些限制和性能影响，我会首先考虑替代方案。
以下是我最喜欢到最不喜欢的解决方案
- 只需创建三个不同的列即可。 3 不同的数据类型(应该)意味着在客户端和服务器端有 3 种不同的解释方式。
- 如果这不是一个选项，请使用
VARCHAR列，这样您至少可以使用LIKE语句。 - 使用
sql_variant数据类型。
编辑 Cudo 为 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
关于sql - 我应该使用 SQL_Variant 数据类型吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9039455/