sql - 在关系数据库中，您将临时属性存储在哪里？

Question

假设您有一个像 INVENTORY_ITEM 这样的关系数据库表。从某种意义上说，它是通用的，库存中的任何东西都需要在这里记录。现在假设有大量不同类型的库存，每种不同的类型可能都有他们想要跟踪的独特字段(例如， fork 可能会跟踪叉齿的数量，但冰箱不会用于该字段)。这些字段必须是用户可定义的每个类别类型。

有很多方法可以解决这个问题:

使用 ALTER TABLE 语句实时添加可为空的列 (yuk)

有两个具有一对一映射的表，INVENTORY_ITEM 和 INVENTORY_ITEM_USER，并使用 ALTER TABLE 语句从后一个表中动态添加和删除可为空的列(更好一点)。

添加一个 CUSTOM_PROPERTY 表和一个 CUSTOM_PROPERTY_VALUE 表，并在用户添加和删除行时在 CUSTOM_PROPERTY 中添加/删除行，并将值存储在后一个表中。这很好且通用，但性能会受到影响。如果每个项目平均有 20 个值，则 CUSTOM_PROPERTY_VALUE 中的行数会以 20 倍的速度增加，并且对于可能要存储的每种不同数据类型，您仍然需要在 CUSTOM_PROPERTY_VALUE 中包含列。

在 INVENTORY_ITEM 上有一个很大的 varchar(MAX) 字段以将自定义属性存储为 XML。

我猜您可以为卡在 INVENTORY_ITEM 表上的每个类别类型创建单独的表，当用户创建库存类型时，这些表会被动态创建/销毁，并且当他们向这些类型添加/删除属性时，列会更新。虽然看起来很乱。

是否有最佳实践？在我看来，选项 4 是干净的，但不允许您轻松地按元数据进行搜索。我以前使用过 3 的变体，但仅在行数非常少的表上使用，因此性能不是问题。在我看来 2 总是一个好主意，但它不太适合自动生成的 Entity Framework ，因此您必须从实体生成中排除自定义属性表，只需编写自己的自定义数据访问代码来处理它。

我错过了任何选择吗？ SQL Server 有没有办法“查看”列中的 XML 数据，以便它现在实际上可以使用选项 4 执行操作？

Answer 1

我在这种情况下使用 xml 类型列...

http://msdn.microsoft.com/en-us/library/ms189887.aspx

在 xml 之前，我们必须使用选项 3。在我看来，这仍然是一个很好的方法。尤其是如果您有一个能够为您正确处理类型转换的数据访问层。我们将所有内容都存储为字符串值，并定义了一个包含转换的原始数据类型的列。

选项 1 和 2 不可行。不要在生产中即时更改数据库架构。

选项 5 可以在单独的数据库中完成......但仍然无法控制模式，用户需要创建表等的权限。