未规范化的表在哪里适用？

Question

使用以下表格是最好的实践或推荐吗？

 id, uid, fieldname, fieldvalue
    4, 12, gender, male
    5, 12, age, 21-30
    6, 12, location, 5
    7, 13, gender, female
    8, 13, age, 31-40
    9, 13, location, 5
    10, 14, gender, female
    11, 14, age, 31-40
    12, 14, location, 6
    13, 15, gender, male
    14, 15, age, 21-30
    15, 15, location, 7

它不是标准化的，您不能指定字段的数据类型。

下面的不是更好吗

id, uid, gender, age, location
4, 12, male, 21-30, 5
5, 13, female, 31-40, 5
6, 14, female, 31-40, 6
7, 15, male, 21-30, 7

我想知道您是否可以证明在数据库中有这样一个表是合理的，我知道第一种方法可能更容易添加更多的字段(而不是更改数据库)，并且可能会删除所有空值。

但是，不能指定数据类型，每次要使用数据时，都必须从字符串进行转换。

那么，有没有将第一个表视为最佳实践或解决方案的场景呢？

Answer 1

在使用这种方法的系统上工作会让你失去理智。执行基本任务所需的查询的复杂性是可怕的，性能是噩梦。

这是一个人的经历：https://www.simple-talk.com/opinion/opinion-pieces/bad-carma/

Answer 2

您可以通过添加另一个表来标准化初始设置：

fieldnames (fnid, name)
fieldvalues (id, uid, fnid, value, unique(uid,fnid))

但是，我建议不要使用它，因为它很复杂--使用单个表要容易得多，除非您要非常频繁地添加和/或删除字段，或者在哪些行获取哪些字段方面可能存在很大差异(在这种情况下，您可能应该重新考虑重新设计您的数据库和应用程序)。

Answer 3

您所描述的第一种类型的结构在属性事先未知的应用程序中非常常见。例如，您可能正在开发一个系统，用户可以在其中保存有关联系人的详细信息。您可能知道要存储的一些详细信息，但不知道其他详细信息。因此，您可以允许用户为联系人定义自定义属性。

当然，这种类型的设计意味着会丢失数据库应用的检查，而必须依赖应用程序应用的检查。这是一个骗局，但如果真的需要灵活性，就不应该成为交易的破坏者。