我有一个包含大量非常具体的列的表,这些列主要是“字符串”。我相信这种硬编码的名字会在以后规则改变时让我感到悲伤。我正在研究使用第二个表的选项,其中每一行都是主表中的一列,每个表的名称都有一个查找键。
我知道这可能看起来是反 ER 最佳实践,但它会很灵活。我可以使用带有子选择的视图,即从 Table1 中选择 (SQL1)、(SQL2) 等。不确定是否可以在 SQLServer 中更新多表视图。
对上述想法不胜感激。
谢谢,
埃德
我有一个包含大量非常具体的列的表,这些列主要是“字符串”。我相信这种硬编码的名字会在以后规则改变时让我感到悲伤。我正在研究使用第二个表的选项,其中每一行都是主表中的一列,每个表的名称都有一个查找键。
我知道这可能看起来是反 ER 最佳实践,但它会很灵活。我可以使用带有子选择的视图,即从 Table1 中选择 (SQL1)、(SQL2) 等。不确定是否可以在 SQLServer 中更新多表视图。
对上述想法不胜感激。
谢谢,
埃德
听起来您正在寻找的是Entity-Attribute-Value
(EAV)表之类的东西。
当涉及到允许进一步定制的灵活性时,EAV 允许一个更加动态的过程,但糟糕的实现可能意味着它不能很好地遵守关系模型。这个 SO question很好地概括了这种解决方案固有的一些问题。
您最好重构列以使用较少上下文特定的命名约定。
避免内平台效应。SQL Server 已经使您能够查询表中的哪些列。请参阅sys.tables和sys.columns。
使用这些查询您拥有哪些列,并根据需要使用标准 DDL 命令添加和删除列。不要害怕规范化、连接等。
当您需要做一些在正常设计中微不足道的事情时,“数据库中的数据库”几乎总是会导致失败。
您可以将该列存储为SQL_VARIANT类型。
这不是世界上最好的做法,但你可以使用它。
create table t (anything sql_variant);
insert t values (current_timestamp);
insert t values (current_timestamp+1);
insert t values (1);
insert t values ('some text');
insert t values (current_timestamp-3);
insert t values (null);
insert t values (2.1234);
insert t values (cast(2 as decimal(10,5)));
insert t values ('some more text');
-- sample based on type
select *
from t
where CAST(sql_variant_property(anything, 'BaseType') as varchar(20)) like '%char';
根据您的问题,您将存储存储在另一列或链接表列中的类型。