1

是否曾经是最佳实践或建议使用以下表格？ 

 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

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

但是，无法指定数据类型，并且每次要使用数据时都必须从字符串转换。

那么是否存在将第一个表视为最佳实践或解决方案的情况？

4

3 回答 3

0

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

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

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

于 2013-04-25T12:03:29.170 回答
0

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

当然，这种设计意味着失去了数据库应用检查，而不得不依赖应用应用检查。这是一个缺点，但如果确实需要灵活性，则不应成为交易破坏者。

于 2013-04-26T16:19:55.110 回答
0

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

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

于 2013-04-30T21:28:46.373 回答