分章节提交的博客文章数据库存储结构如何选型？

方案评估与建议 #

首先明确：给每篇文章单独创建章节表属于非常不推荐的不良实践，完全不符合关系型数据库的设计规范。当你博客文章数量上升后，库内会出现成百上千张结构完全一致的章节表，无论是查询、维护、备份都会变得极难处理。 #

修正后的分表方案（一对多关联结构） #

你原本的思路优势可以完整保留，只需要调整表结构即可，无需为单篇文章创建独立表：

TABLE posts:
  id INT PRIMARY KEY AUTO_INCREMENT
  title VARCHAR(255) NOT NULL
  -- 可拓展其他文章公共字段：发布时间、作者、分类、浏览量等

TABLE chapters:
  id INT PRIMARY KEY AUTO_INCREMENT
  post_id INT NOT NULL -- 关联posts表的id字段，标记章节所属文章
  chapter_order INT NOT NULL -- 存储章节排序序号，避免查询结果顺序错乱
  chapter_header VARCHAR(255) NOT NULL
  chapter_content TEXT NOT NULL
  FOREIGN KEY (post_id) REFERENCES posts(id) ON DELETE CASCADE

这种结构的优势：

• 保留章节独立可识别的特性，渲染时直接按post_id+chapter_order查询即可直接使用，不需要额外解析内容
• 拓展性极强：后续要做章节单独点赞、锚点跳转、部分章节付费可见、章节阅读时长统计等功能，只需在chapters表加对应字段即可，不需要改动内容结构
• 内容修改成本低：如果仅需要修改某一章节的标题或内容，直接更新chapters表对应单行记录即可，不需要处理整篇长文本
  劣势：
• 写入和查询需要处理关联表，新增/修改文章时要先写入posts表，拿到生成的post_id再批量写入chapters表
• 如果博客永远不会用到任何和独立章节相关的拓展功能，这种结构相比单表会略有冗余

单表存储整段内容方案 #

这种方案的优势：

• 结构简单，写入查询都是单表操作，开发速度快
• 不需要处理关联逻辑，适合极简博客场景
  劣势：
• 所有和章节相关的需求都要依赖内容解析实现：比如生成章节目录、给章节加锚点，都需要写正则或HTML解析逻辑拆分内容，出错概率高
• 完全无法实现章节粒度的修改、统计需求，后续拓展性极差

选择建议 #

如果当前已经明确有章节独立展示、生成目录、章节粒度操作的需求，直接选择修正后的一对多分表结构，完全符合数据库设计规范，没有任何问题。
如果只是做非常简单的个人博客，后续也不打算做任何章节相关的拓展功能，选择第二种单表方案更节省开发成本。

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