数据库设计，空列或添加新列或其他内容

Question

我有一个我正在重新设计的产品。

旧的数据库设计是...... ID，键，值，所有字符串，其中值可以是数字，文本或日期。试图对这些数据进行特定类型的搜索是不可能的（或者说慢到无关紧要）。 Key是一组对象所具有的值，所以说obj a的生日为1/12/1969，名称为Dan，phoneNumber为555-555-5555，数据库存储为

1969年1月12日的生日 一个名叫丹 a phonenumber 555-555-5555

我想重新设计它，以便键实际上是字段，所以我们会有这个

a 1/12/1969 Dan 555-555-5555

我担心的是，当用户进入并添加新密钥（例如手机）时，添加列可能需要很长时间和/或让用户感到困惑。

用户很可能在开始时定义密钥，但在使用产品多年后，密钥可能会被添加。

我曾经想过将我们支持的不同类型的几列添加为空，然后将其重命名为用户添加它们，是的，当我用完这些空列时，我仍然会遇到问题，但我的大多数用户都不会看到这个。我不喜欢这个答案，但我更喜欢alter table场景。

任何人有任何想法或想法？

最后，这是一个产品，其中数据库后端可以是oracle，sql server或access（可能不是，但可能）

Answer 1

您可以将这两种设计结合起来，花时间真正定义实际表格中实际需要的95％。然后有一个EAV表，用于必要的可自定义字段。如果您真正做好设计工作以包含通常需要的东西，大多数客户将永远不会添加一个。

另一种方法是创建一个包含用户可以定义的一组可自定义字段的表，然后它们将仅限于6个自定义字段。

第三种方法是让自定义字段位于与主表具有一对一关系的separte表中。这与左连接相结合。当客户添加新字段时，您仍然需要更改此结构，但是如果它们添加到常规表中，它应该会中断其他数据。

XML数据类型或大型varchar字段（例如SQL Server中的varchar（max））可能是另一种可能性，尤其是如果您只想显示自定义数据而不是对其进行任何特定查询。

Answer 2

您所描述的内容称为Entity Attribute Value。这样的建模很困难，你决定的任何解决方案都可能至少有一些缺点。您应该看一下这个有关该主题的非常全面的讨论的stackoverflow问题： Entity Attribute Value Database vs. strict Relational Model Ecommerce

Answer 3

键/值表设计是完全垃圾，所以我很高兴你摆脱它！

我建议不要在表格中添加额外的列以供将来扩展。每个表格的每个字段都应该有一个独特的解释，并且应该被限制为只能为该解释保留合理的值。

如果您想拥有用户设计的自定义字段，那么键/值系统可能就此就足够了（而且只有这一点），并且理解这些用户设计数据的查询和约束将更加困难和低劣。

Answer 4

您可以将键映射到oracle数据类型，并在检索值时根据数据类型使用特定函数。

e.g。 ID KEY数据库值 出生日期为1912年1月12日 一个名字串丹 a phonenumber string 555-555-5555

所以每个用户信息都有3行，您可以根据需要添加更多行。 检索时你可以使用基于DATATYPE值的解码。

然而，这种方法可能会增加空间利用率。