问答和博客站点 - 保留一个 table 还是拆分为 2 个或 3 个 table？
Q&A, and Blog Site - Keep to one table or split to 2 or 3 tables?
正在构思 Question/Answer/Blog 网站。对于其中每一个的内容，我可以将它们全部存储在一个 table 中，其中一些列应用于或不应用于这些不同类型中的每一种，并使用类型列来区分每个 - 或者，我可以将它们分成两个 tables Question/Blog 和 Answer（或其他组合），或分为 3 tables 每个类型一个。
在第一个 table 想法中，列如下所示：
id / heading / detail / type / qid
type 列将通过 'question' / 'blog' / 'answer'
qid 将引用 Answer
问题：使用标题、详细信息、类型
BLOG：使用标题、详细信息、类型（qid 匹配问题，如果指定为答案，但不是典型的）
ANSWER：使用详细信息、类型、qid（qid 匹配问题 id，不使用标题栏）
可能还有一两列（未显示）可能适用于一种类型而不适用于另一种类型。
我认为将所有内容存储在一个 table 中可能会使它们之间存在关系的查询更简单，但是 table 变得更大更快...什么是 database/table 这样设计的目的是希望这个社区能够随着时间的推移变得相当大（10K 到 100K 活跃用户）？
一些典型的关系：
A 将作为 Q 的答案与 Q 相关。Q 可以有多个答案。
Q、A、B 将全部列在同一个 window 上，复选框选择 show/hide Q&A 或 B 或 BOTH。
Q 的答案可以与 A 或 B 相关联（用户可以指定一个博客作为答案，但预计频率会降低）
A的数量远远超过全部，Q次之，B最少。
我倾向于一个 table 支持 Q/B，另一个 table 支持 A - 但我没有明确的理由。 （没有足够的经验来看待可扩展性、可维护性、常态性、可靠性、清晰度等方面的事物以及未来的影响）也许可扩展性和可维护性会被优先考虑？
感谢您的想法！
I think storing all in one table may make queries simpler where there is a relationship between them, but the table gets much larger quicker... What is a good approach to a database/table design like this with the expectation this community can grow quite large over time (10K to 100K active users)?
即使是资源最少的 mysql 服务器也可以处理 table 中有数千万行的服务器。这不是忽视数据库规范化基本原则的借口。
您不应将您的核心 table 设计与性能调整和优化或可伸缩性混为一谈。
我的有根据的猜测
问题和博客本质上是同一实体的子类型。我会使用相同的 table，也许称它为 "content" 或 "item"。使用 tinyint 或 char[1] 列来指定它是博客还是答案。
"type specific" 列可能保证子类型 table 具有定义关系（共享项目 table 的键），这将允许您加入并获取那些特定类型属性，如果你需要的话。这在编码时更复杂，如果您只有少数这些属性，那么将它们放在项目 table 中会更简单并且可能不会有太多开销。例如，如果一行中没有未使用的 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
这是大多数此类系统的最简单形式的基本框架。它基于简单的一对多关系（一个项目可以有多个答案）。如果您考虑一下，答案与评论并没有什么不同。
正在构思 Question/Answer/Blog 网站。对于其中每一个的内容，我可以将它们全部存储在一个 table 中，其中一些列应用于或不应用于这些不同类型中的每一种，并使用类型列来区分每个 - 或者，我可以将它们分成两个 tables Question/Blog 和 Answer（或其他组合），或分为 3 tables 每个类型一个。
在第一个 table 想法中，列如下所示： id / heading / detail / type / qid
type 列将通过 'question' / 'blog' / 'answer'
来区分每个列
qid 将引用 Answer
的问题 ID
问题：使用标题、详细信息、类型
BLOG：使用标题、详细信息、类型（qid 匹配问题，如果指定为答案，但不是典型的）
ANSWER：使用详细信息、类型、qid（qid 匹配问题 id，不使用标题栏）
可能还有一两列（未显示）可能适用于一种类型而不适用于另一种类型。
我认为将所有内容存储在一个 table 中可能会使它们之间存在关系的查询更简单，但是 table 变得更大更快...什么是 database/table 这样设计的目的是希望这个社区能够随着时间的推移变得相当大（10K 到 100K 活跃用户）？
一些典型的关系：
A 将作为 Q 的答案与 Q 相关。Q 可以有多个答案。 Q、A、B 将全部列在同一个 window 上，复选框选择 show/hide Q&A 或 B 或 BOTH。 Q 的答案可以与 A 或 B 相关联（用户可以指定一个博客作为答案，但预计频率会降低） A的数量远远超过全部，Q次之，B最少。
我倾向于一个 table 支持 Q/B，另一个 table 支持 A - 但我没有明确的理由。 （没有足够的经验来看待可扩展性、可维护性、常态性、可靠性、清晰度等方面的事物以及未来的影响）也许可扩展性和可维护性会被优先考虑？
感谢您的想法！
I think storing all in one table may make queries simpler where there is a relationship between them, but the table gets much larger quicker... What is a good approach to a database/table design like this with the expectation this community can grow quite large over time (10K to 100K active users)?
即使是资源最少的 mysql 服务器也可以处理 table 中有数千万行的服务器。这不是忽视数据库规范化基本原则的借口。
您不应将您的核心 table 设计与性能调整和优化或可伸缩性混为一谈。
我的有根据的猜测
问题和博客本质上是同一实体的子类型。我会使用相同的 table，也许称它为 "content" 或 "item"。使用 tinyint 或 char[1] 列来指定它是博客还是答案。
"type specific" 列可能保证子类型 table 具有定义关系（共享项目 table 的键），这将允许您加入并获取那些特定类型属性，如果你需要的话。这在编码时更复杂，如果您只有少数这些属性，那么将它们放在项目 table 中会更简单并且可能不会有太多开销。例如，如果一行中没有未使用的 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
这是大多数此类系统的最简单形式的基本框架。它基于简单的一对多关系（一个项目可以有多个答案）。如果您考虑一下，答案与评论并没有什么不同。