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

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

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

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

Answer 2

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

当然，这种类型的设计意味着一个人丢失了数据库应用的检查，并且必须依赖应用程序应用的检查。这是一个骗局，但如果确实需要灵活性，则不应该是一个交易破坏者。

Answer 3

使用该方法的系统将使您失去理智。为执行基本任务所需的查询的复杂性是可怕的，性能是一场噩梦。

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

未规范化的表格适用于何处？

3 个答案: