Sql表动态单元格类型

Question

假设我有一个Product和一个ProductType表。我想要一个表格，我可以为每种产品类型存储特殊列。特殊列（属性）可以是任何类型。

现在我们每个ProductType都有一个名为Product_%ProductTypeId%的表，这是我真的不喜欢的解决方案 - 有什么建议吗？

我的想法是有一张表ProductTypeColumns和cols：

Id | ProductTypeId | ColumnName | Value  | ColumnType

我不喜欢这个是我失去了类型安全性，列Value将是一个字符串类型，这意味着我必须始终转换为和来自。

此外，此表将用于生成报告..具有“动态”列可能是个问题。

Answer 1

类别层次结构（又称“继承”，“子类型”，“子类”）怎么样？

我个人会使用名称/价值对解决方案（在您的问题中描述），只有当列不预先确定时。

如果您事先了解所有列并且它们不太可能更改，那么实现类别层次结构while not without complications将保留类型安全性并更好地通过DBMS实现声明性完整性（例如，您可以拥有特定于产品的UNIQUE，FOREIGN KEY或CHECK约束。）

Answer 2

这称为EAV 您可以在SO上找到有关EAV和SQL Server的一些问题：

• EAV over SQL Server
• Performance of large EAV/open schema systems on SQL Server

这是一个很多不同的人会有不同意见的主题 有人会说你应该坚持使用Product_%ProductTypeId%表，有些人会说你的ProductTypeColumns表更好。

基本上，我在ProductTypeColumns阵营 我们在工作中也使用类似的东西：
我们的表包含订单商品的属性（超过一百万个订单商品和超过2.5亿个属性），我们现在使用它近十年了。
缺点：没有类型安全（如您所述）和querying can be a bit complicated。

但对我们而言，这是唯一可能的方式，因为我们有超过1000个属性，超过100种产品，每种产品可以有100到300个属性。对于这些尺寸，属性表是唯一可能的方式 但它可能不是每个人的最佳解决方案，我不知道它是否是最适合您的解决方案。

如果您的产品数量和特殊属性不是那么大，也许您可​​以放弃第一个建议（Product_%ProductTypeId%表格）。
这肯定会更容易查询，但如果有太多可能的产品和属性组合，它可能不是一个选项。

通常，这取决于。