SQL 模式设计建议答案

【问题标题】：SQL Schema Design AdviceSQL 模式设计建议
【发布时间】：2017-12-03 19:35:06
【问题描述】：

我有一个“用户”表，其中有一堆关于我的用户的具体“确定”属性，所有这些属性都必须存在并且它们的真实性是确定的，然后我有一个单独的表“用户派生”，其中所有数据都在这个表中是机器学习模型猜测的我的用户的派生属性。例如：“年龄”可能是某个属性，因为他们提供给我，“身高”或“头发颜色”可能是派生属性，因为 ML 模型从图片中猜到了它。主要区别是“用户”表中的所有属性都是由用户自己提供给我的，并且具有完全确定性，而“用户派生”表中的所有属性都具有与之相关的值和确定性，并且是由我的系统猜测的.另一个区别是“users”表的所有属性都存在于每个用户中，而“users_derived”表中的任何属性可能存在也可能不存在。我不时添加新的机器学习模型，这些模型也会猜测用户的更多属性。

我的问题是如何为“users_derived”表做架构。我可以这样做：

userid  |  prop1  | certainty1  |  prop2  | certainty2 | prop3 |  etc ...
123         7         0.57         5'8''       0.82       red
124         12        0.6          NULL        NULL       black
125         NULL      NULL         6'1''       0.88       blonde

或者我可以这样做，但索引略有不同：

userid   |  property  |  value   |   certainty 
 123           1           7            0.57
 123           2          5'8''         0.82
 124           1           12           0.60
 123           3          red           0.67
 124           3          black         0.61
 125           2          6'1''         0.88
                       etc ....

因此，折衷看起来像第二种方式，它没有那么规范化并且可能稍微难以查询，但您不必提前知道您关心的所有属性——也就是说，如果我想添加新属性没有架构更改。此外，不必有任何 NULL 点，因为如果我们没有该属性，但我们只是没有一行。我错过了什么？第一种方法有什么好处？我可以对第一个模式执行的查询在第二个模式中是困难的还是不可能的？第二种方式是否需要更多空间来进行索引以使其更快？

【问题讨论】：

标签： mysql postgresql database-design schema entity-attribute-value

【解决方案1】：

第二种方式是more规范化的。表和索引都可能更紧凑，尤其是在第一种形式相对稀疏的情况下。虽然这两种形式对不同的查询有不同的权衡，但总的来说第二种形式更灵活，更适合各种各样的查询。如果您想将数据从规范化形式转换为交叉表形式，Postgres 的 tablefunc 扩展中有一个 crosstab 函数可用于此目的。规范化交叉表数据将更加困难，尤其是在列数不确定的情况下——但对于某些类型的查询，您可能需要这样做。

【讨论】：