sql中的字符串类型值表，有更好的方法吗？ （我们正在使用MSSQL）

Question

我们在一个表中有一个包含属性名称的表布局，在第二个表中有值，在第三个表中有值。 （是的，我们正在SQL中重新实现表。）

我们加入所有三个以获取特定项目的属性值。

不幸的是，值可以有多个数据类型double，varchar，bit等。目前，共识是串行键入所有值并将类型名称存储在值旁边的列中。

tblValues DataTypeName nvarchar

有更好，更清洁的方法吗？

澄清：

我们的要求声明我们必须在运行时添加新的“属性”而不修改db模式

我不想使用EAV，但这是我们现在的方向。

此系统目前存在于使用传统数据库设计的SQL服务器中，但我无法看到一种方法来满足我们在不迁移到EAV的情况下不修改数据库模式的要求。

Answer 1

实施'EAV模型'实际上只有两种模式（假设你想做的事）：

1. 按照您的描述实现它，您可以在其中显式存储属性值类型以及值，并使用它将存储的字符串值转换为访问数据库的应用程序中的相应“本机”类型
2. 为可能存储为属性值的每种可能数据类型添加单独的列。您还可以包含一个指示属性值类型的列，但不一定非必要。

解决方案1是一种更简单的设计，但它会产生将根据需要将表中存储的字符串值转换为适当数据类型的开销。

解决方案2具有将值存储为适当的本机类型的优点，但它必然需要更多但不一定更多的空间。如果此表中没有很多行，这可能没有实际意义。您可能希望添加一个检查约束，该约束仅允许不同值列中的一个非NULL值，或者如果您包含一个类型列（以避免检查不同值列中的非NULL值），存储在类型列中的值与哪个值列包含非NULL值之间不匹配。

正如HLGEM在她的回答中所述，这不如标准关系设计更受欢迎，但我更同情EAV模型表设计用于数据，例如应用程序选项设置。

Answer 2

好吧不要那样做！如果你这样做，你将失去拥有数据类型的所有值。你不能正确地约束它们（并且我会保证它最终得到坏的数据）并且你必须将它们转换回适当的类型以用于数学或日期计算。总而言之，这是一场失败者。

您的整个设计无法很好地扩展。阅读您不希望在关系数据库中使用EAV表的原因。它不仅通常较慢，而且异常难以查询，尤其是报告。

也许noSQL数据库更适合您的需求或适当的关系设计而不是EAV设计。是否真的很难弄清楚每个表真正需要哪些字段，或者你的开发人员只是懒惰？您是否因为灵活性而牺牲性能 - 大多数用户会讨厌的灵活性？特别是当它意味着糟糕的表现？您是否曾使用过这样设计的数据库来尝试做任何事情？