类Quora应用的关系型数据库Schema适配性问询与方案评估

一、先明确：类Quora应用的典型关系型Schema该包含哪些核心部分 #

一个能支撑Quora核心功能的关系型Schema，至少得覆盖这些模块：

• 用户模块：user_table(id, username, email, password_hash, created_at, reputation, bio, is_verified, ...)——用户的声望、认证状态、社交关系是Quora的核心之一，这些字段缺一不可。
• 内容核心模块：
  • question_table(id, title, content, user_id, created_at, updated_at, view_count, vote_count, is_anonymous, ...)——Quora的问题是标题+详情的结构，时间线、投票数、匿名状态都是核心属性；
  • answer_table(id, content, question_id, user_id, created_at, updated_at, vote_count, is_accepted, is_anonymous, ...)——回答的投票数、采纳状态、匿名属性直接影响排序和展示；
  • comment_table(id, content, source_id, source_type, parent_comment_id, user_id, created_at, ...)——需要parent_comment_id来实现嵌套回复，这是Quora评论区的基础体验；
• 社交与推荐模块：
  • vote_table(id, user_id, target_id, target_type, vote_type, created_at)——记录用户对问题/回答的点赞/踩，是内容权重计算的核心；
  • tag_table(id, name) + question_tag(id, question_id, tag_id)——标签是内容分类、个性化推荐的基础；
  • follow_table(id, follower_id, target_id, target_type, created_at)——支持用户关注其他用户、问题或专栏，生成个性化Feed；
  • bookmark_table(id, user_id, target_id, target_type, created_at)——用户收藏内容的功能。

二、Quora为啥放着常规关系型Schema不用，搞无Schema存储在MySQL？ #

Quora的业务特性决定了它需要极致的灵活性：

• 快速迭代的刚需：作为内容平台，Quora经常要加新功能——比如突然要给问题加「是否允许匿名回答」、给回答加「编辑历史」、给用户加「领域认证」。常规Schema需要执行ALTER TABLE，在高并发场景下这会导致服务卡顿甚至不可用，而无Schema（比如用JSON字段存储动态属性）可以直接在应用层扩展，不用动表结构；
• 多态内容的极致扩展：除了问题、回答、评论，Quora还有动态、专栏、投票等N种内容类型，每种类型的属性差异极大（比如专栏有「订阅数」，投票有「选项列表」）。常规Schema要么建一堆表，要么加大量冗余字段，而无Schema可以用统一的存储结构，把每个内容的个性化属性塞进JSON字段里；
• 历史数据兼容：Quora运营多年，旧数据和新数据的属性差异很大（比如早期没有匿名提问功能），无Schema可以天然兼容不同版本的内容属性，不用做复杂的数据迁移；
• 个性化与全球化需求：不同地区的用户可能需要不同的内容属性（比如部分地区的问题要加「地区标签」），无Schema可以轻松适配这些个性化需求，不用修改表结构。

三、你的Schema具体哪里适配不了Quora？ #

你的设计太精简了，完全没覆盖Quora的核心业务需求，具体问题如下：

1. 缺失核心业务字段，撑不起Quora的基础功能 #

• 没有用户表：Quora的用户声望、认证状态、社交关系是核心，你完全没设计user_table，连最基本的用户身份标识都缺失；
• 问题表缺少关键属性：Quora的问题是「标题+内容」结构，你只有content；没有created_at/updated_at就没法做时间线排序；没有vote_count、tags就没法做内容权重计算和分类推荐；没有匿名状态字段，没法支持Quora的匿名提问功能；
• 回答表缺少核心属性：没有vote_count就没法按热度排序回答；没有is_accepted就没法标识提问者采纳的回答；没有时间字段，没法展示回答的发布/修改时间；
• 评论表缺少嵌套支持：Quora的评论是可以嵌套回复的，你的Schema没有parent_comment_id，只能做平级评论，完全不符合用户体验；也没有created_at，没法展示评论的时间顺序。

2. 无法支撑快速迭代与动态属性需求 #

你的Schema是固定结构，一旦Quora要加新属性（比如给问题加「是否锁定」、给回答加「编辑历史」），就必须修改表结构，这在Quora的高并发场景下是致命的——ALTER TABLE会锁表，导致服务不可用。而无Schema的方式可以用JSON字段轻松扩展这些属性，不用动表。

3. 缺失核心关联表，没法做社交与推荐 #

Quora的核心是社交和个性化推荐，你的Schema完全没有投票表、标签关联表、关注表、收藏表这些模块：

• 没有投票表，就没法计算内容的热度权重，没法实现「热门回答」排序；
• 没有标签关联表，就没法做内容分类，没法给用户推荐感兴趣的问题；
• 没有关注表，就没法生成个性化Feed，用户看不到自己关注的人/问题的动态；
• 没有收藏表，用户没法保存自己感兴趣的内容。

4. 无法处理多态内容的扩展 #

Quora除了问题、回答、评论，还有很多其他内容类型（比如动态、专栏、投票），你的Schema只覆盖了三种，要是新增内容类型，要么新建表，要么修改comment_table的source_type，但每种内容的属性差异极大，固定Schema没法灵活存储这些差异，而无Schema可以用统一的方式存储所有内容的属性，轻松扩展。

内容的提问来源于stack exchange，提问作者Oceanvijai