MYSQL和规范化：如何处理许多可选字段？

Question

我有一个个人资料页面，上面有大约20个可选字段。 为了保持规范化，我必须创建20个不同的表，然后在其中进行20个JOINS的查询。 这对我来说似乎有点过头了。

这是最好的方法吗？

你建议我保持标准化吗？

Answer 1

一个很好的方法（虽然有点令人困惑，除非你知道发生了什么）使用相同的设计wordpress使用 - 据我记得它被称为实体属性值（感谢@Matt Fenwick）。 https://stackoverflow.com/tags/eav/info

基本的想法是，你有两个表，而不是你的20个INNER JOIN表来存储赔率和结束。 一个存储您的实体（一个帖子在wordpress'案例中），第二个存储您的所有可能性和结束 - 或者WP指向它的元数据。 您没有每个数据点的列，而是有一个名称列，一个用于值，一个用于此属性适用的实体的ID。

通过这种方式，您可以节省大量的SQL，扩展期间的麻烦以及开始构建它所需的时间。 如果您需要为另一个房产提供服务，那么您只需将其与其他房产一起打包 - 不要破坏架构。

关于WP数据库布局的更多细节（这里我主要考虑的是wp_posts和wp_postmeta表）： http ：//codex.wordpress.org/Database_Description

所以一个例子可能是（伪代码，对不起）：

table: yourEntity
entityID  int, primary key, auto increment
title     varchar

table: yourEntityMeta
entityID  int, non-unique key
name      text
value     text

这样，您可以为每个实体提供任意数量的属性，对具有NULL值的未使用列和18个需要连接的表没有限制或性能问题。

希望这可以帮助

注意：此问题的一个问题（在评论中由@ypercube指出）是使用这意味着您不能为每个属性指定数据类型，即日期属性将存储为文本，如布尔值或int。 您也无法使用foriegn键链接到有效值表（感谢@Catcall）。 在沿着这条路走下去之前，你需要仔细考虑。

Answer 2

我只会将可空列用于可选字段。 该表将变得非常大，但是如此多的连接只会降低您的性能，我找不到这些字段应该归一化的原因，如果它们属于一个对象并且将一起更新。

Answer 3

如果选项字段是常量，请考虑使用ENUM（2-20个选项），但是这种方法有自己的缺陷。

如果您主要关心的是数据库规范化，那么即使您有20个选项字段，也应该为每个选项字段分别设置“查找”表，这样就不会存储重复数据。

此外，如果您决定在将来更改选项，它将使您的表在将来更容易维护。

JOIN语句也不错，MySQL可以在一个查询中支持多达61个表。 我已经在我的这个问题中探讨了这个话题。