哪个表架构更好？答案

【问题标题】：Which table schema is better?哪个表架构更好？
【发布时间】：2011-11-11 08:33:57
【问题描述】：

哪种结构更好？

表1

postid category1 category2 category3
2            a         b        d

3            a         c       null

或

张贴表

postid
2
3

category_option 表

category     option

category1      a
category2      b
category3      c
category4      d

option_post 表

post option
2      a
2      b
2      d 
3      a
3      c

似乎第一个结构的构建查询比第二个结构更容易。

【问题讨论】：

【解决方案1】：

这两种结构模拟不同的事物。第一个严格地只允许（最多）3个类别（并按位置区分类别），而第二个可以模拟任意数量的类别（不按位置区分）。哪个更好实际上取决于您要完成的工作...

在纯技术层面上，第二个可能需要对某些查询进行 JOIN，其中第一个可以满足来自单个（且唯一）表的查询。这是否是一个问题，再次，取决于环境......

【讨论】：

当你说连接表时，你的意思是 select * from table as t1,table as t2 and t1.option=a and t2.option=b and t1.postid=2 and t1.postid= t2.postid ?这是一个优化查询？有没有更好的解决方案？
是的，类似的东西，虽然通常使用更现代的语法（谷歌为 JOIN 关键字）。 JOIN 可能非常快或非常慢，这取决于许多因素，至少不是索引。我强烈建议阅读use-the-index-luke.com，了解一般索引和特别是 JOIN 的性能影响。

【解决方案2】：

取决于要求...

您是否预计随着时间的推移会增加选项的数量？

您的第一个选项更容易编码，第二个选项更模块化设计和可扩展性。

【讨论】：

【解决方案3】：

这在很大程度上取决于类别的性质。如果列表是固定的并且不太可能增长，那么第一个结构就可以正常工作并且更容易使用。如果类别列表可能会增长，那么第二个选项会增长得更好。

类别值是否稀疏也很重要。如果大多数类别都没有值，那么第二种方法将占用更少的空间。如果每个项目在每个类别中都有值，这不是问题。

在这种情况下，了解“可能”的含义很重要。这并不意味着设计师认为它不会增长。这意味着类别列表已被充分理解和成熟，因此不太可能增长。我一直在寻找示例，但没有想到。

选择第一个选项有充分的理由，但请谨慎操作 - 在生产系统中切换到第二个选项将是一场噩梦。

【讨论】：

【解决方案4】：

第二个更好。第一种是违反第一范式：

【讨论】：

【解决方案5】：

第二个更好。这是典型的 many2many 连接表案例。

如果你用第一种方式来做，如果有新的类别类别 4,5,6,7,8...来，你会怎么做？向表中添加新列？

而且，我不知道您是否有“多少个带有类别选项‘c’的帖子”之类的要求？第二个很容易做统计，但是第一个......

【讨论】：

【解决方案6】：

category_option 必须具有类别 id 才能与 opton_post 建立联合表，否则无法创建第二个表结构。

通过这种结构，您可以在这里实现两件事。

1) 与帖子到类别建立一对一的关系。（这意味着您可以在未来需要时添加更多类别）

2) 在这个结构中 null 值自动避免。这意味着不再处理表或 sql 查询中的空值。

希望这会有所帮助。

【讨论】：