时间戳

首页 > 解决方案 > 问答和博客网站 - 保留一张桌子还是分成 2 或 3 张桌子？

mysql - 问答和博客网站 - 保留一张桌子还是分成 2 或 3 张桌子？

问题描述

研究问题/答案/博客网站的想法。对于其中每一个的内容，我可以将它们全部存储在一个表中，其中一些列应用或不应用到这些不同类型中的每一个，并使用类型列来区分每个 - 或者，我可以将它们分成两个表问题/博客，和答案（或其他组合），或分成 3 个表，每种类型一个。

在一个表的想法中，列看起来像：id/heading/detail/type/qid

问题：使用标题、详细信息、类型

BLOG：使用标题、详细信息、类型（qid 匹配问题，如果分配为答案，但不典型）

回答：使用详细信息、类型、qid（qid 匹配问题 id，不使用标题列）

可能有另一列或两列（未显示）可能适用于一种类型而不适用于另一种类型。

我认为将所有内容存储在一个表中可能会使查询在它们之间存在关系时变得更简单，但表会更快地变大......对于这样的数据库/表设计有什么好的方法，期望这个社区可以发展得相当大随着时间的推移（10K 到 100K 活跃用户）？

一些典型的关系：

A 将与 Q 相关，作为 Q 的答案。Q 可以有多个答案。Q、A、B 都将列在同一个窗口中，并带有复选框选项以显示/隐藏 Q&A 或 B 或两者。Q 的答案可以与 A 或 B 相关联（用户可以将博客指定为答案，但希望不那么频繁）A 的数量将远远超过所有这些，Q 关注和 B 最少。

我倾向于 Q/B 的一张桌子和 A 的另一张桌子 - 但我没有一个很好的明确理由。（没有足够的经验来看待可扩展性、可维护性、正常性、可靠性、清晰度等和未来影响方面的事情）也许可扩展性和可维护性会被优先考虑？

谢谢你的想法！

标签： mysqlsqldatabasedatabase-design

解决方案

我认为将所有内容存储在一个表中可能会使查询在它们之间存在关系时变得更简单，但是表会更快地变大......对于这样的数据库/表设计有什么好的方法，期望这个社区可以发展得相当大随着时间的推移（10K 到 100K 活跃用户）？

即使是资源最少的 mysql 服务器也可以处理包含数千万行的表。这不是忽视数据库规范化基本原则的借口。

您不应该将核心表设计与性能调整和优化或可伸缩性混为一谈。

我有根据的猜测

问题和博客本质上是同一实体的子类型。我会使用同一张表，也许称它为“内容”或“项目”。使用 tinyint 或 char[1] 列来指定它是博客还是答案。

“类型特定”列可能需要具有定义关系（共享项目表的键）的子类型表，如果需要，您可以加入并获取这些类型特定的属性。编写代码更复杂，如果您只有少数这些属性，那么将它们放在项目表中会更简单，并且可能不会有太多开销。例如，如果一行没有未使用的 varchar() 列，则没有实际成本。这些列不得声明为非空，因为它们是可选的。

user
----
id (pk) unsigned integer
username varchar(100)
etc..

item
----
id (pk) unsigned integer
user_id (fk) (author of question/blog post)
type not null unsigned tinyint (1 = "blog", 2="question")
title varchar(100)
detail text
created_at timestamp

answer
------
id (pk) unsigned integer
user_id (fk) (stores user key)
item_id (fk) (stores parent item key)
details text
created_at timestamp

这是大多数此类系统以最简单的形式具有的基本骨架。它基于简单的一对多关系（一个项目可以有多个答案）。如果您考虑一下，答案与评论并没有真正的不同。

推荐阅读