我正在做一个关于问答博客网站的想法。对于每一种类型的内容，我可以将它们全部存储在一个表中，其中一些列适用或不适用每一种类型，并有一个类型列来区分每一种类型--或者，我可以将它们分成两个表QuestionBlog和Answer（或其他组合），或者分成3个表，每个类型一个表。
在一个表的想法中，列会是这样的： id 标题 详细类型 qid
类型栏将通过 "问题""博客""答案 "来区分每个类型
qid将参考该问题的id作为答案。
问题：使用标题、细节、类型。
BLOG：使用标题、细节、类型（qid与问题相匹配，如果指定为答案，但不是典型的）。
答案：使用细节、类型、qid（qid与问题id匹配，不使用标题栏）。
可能还有一两列（未显示），可能适用于一种类型，而不是另一种类型。
我认为把所有的数据都存储在一个表中，在它们之间有关系的情况下，可能会使查询变得更简单，但是这个表会变得更大更快...... 对于这样一个数据库表的设计，预计这个社区会随着时间的推移而变得相当大（10K到100K的活跃用户），有什么好的方法？
一些典型的关系。
A将与Q相关联，因为是Q的答案，可以有多个Q的答案.Q，A，B都将被列在同一个窗口上，有复选框选择显示Q&A或B或BOTH.Q的答案可以与A或B相关联（用户可以指定一个博客作为答案，但期望较少）A的数量将远远超过所有的答案，Q其次，B最少。
我倾向于QB一个表，A另一个表--BUT我没有一个很好的明确的理由。 (没有足够的经验，无法从可扩展性、可维护性、规范性、可靠性、清晰性等方面和未来影响来看待问题)也许可扩展性和可维护性会优先考虑？
谢谢你的想法!
我觉得把所有的内容存储在一个表中，在它们之间有关系的情况下，可能会使查询更简单，但表变大的速度更快...... 对于这样一个数据库表的设计，有什么好的方法，可以让这个社区随着时间的推移变得相当大（10K到100K的活跃用户）？
即使是一个资源最少的mysql服务器，也可以应付几千万行的表。 这不是忽视数据库规范化基本原则的借口。
你不应该将你的核心表设计与性能调整和优化或可扩展性混为一谈。
我的猜测是
Question和Blog本质上是同一个实体的子类型。 我会使用相同的表，也许叫它 "内容 "或 "项目"。 使用一个 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
这是大多数这类系统最简单的形式会有的基本骨架。它的前提是一个简单的One to Many关系（一个Item可以有Many Answers）。 如果你考虑一下，一个答案和一个评论其实没什么区别。