Sequelize ORM 入门与模型设计

刚开始把博客系统往关系型数据库上迁的时候，我最先补的一块不是查询，而是模型设计。因为模型边界一旦定错，后面的列表、详情、标签、归档都会变得越来越绕。

Sequelize 的价值，不只是“把 SQL 换成 JavaScript 写法”，而是给我们一套更稳定的领域建模方式。对于博客这种内容系统，最常见的核心对象通常只有几个：

• Post：文章主体，承载标题、摘要、正文、发布时间、状态。
• Category：文章一级分类。
• Tag：更细颗粒度的主题标签。
• Author：作者信息。

一个比较稳妥的做法，是先把内容对象拆清楚，再去考虑字段是否要追求“一把梭”。

const { DataTypes } = require('sequelize');

module.exports = (sequelize) => {
  const Post = sequelize.define('Post', {
    id: {
      type: DataTypes.BIGINT,
      primaryKey: true,
      autoIncrement: true,
    },
    title: {
      type: DataTypes.STRING(200),
      allowNull: false,
    },
    slug: {
      type: DataTypes.STRING(200),
      allowNull: false,
      unique: true,
    },
    summary: {
      type: DataTypes.STRING(500),
      allowNull: false,
    },
    content: {
      type: DataTypes.TEXT('long'),
      allowNull: false,
    },
    status: {
      type: DataTypes.ENUM('draft', 'published'),
      defaultValue: 'draft',
    },
    publishedAt: {
      type: DataTypes.DATE,
      allowNull: true,
    },
  }, {
    tableName: 'posts',
    underscored: true,
  });

  return Post;
};

我在做博客内容表时，有三个经验很实用。

1. 不要一开始把所有业务状态都塞进模型

很多人建表时喜欢直接上十几个状态位，比如推荐、置顶、精选、可评论、可搜索、是否同步。这种设计前期看着完整，后期往往最难收拾。

更好的方式是先只保留几个真正影响主流程的字段：

• 是否发布
• 发布时间
• slug 是否唯一
• 是否允许展示

其余像“推荐位”“专题位”之类，更适合用独立配置表或内容编排层去解决。

2. slug 一定要尽早定成唯一字段

博客系统里最怕后期 URL 改来改去。Sequelize 模型层直接把 slug 设成唯一键，可以在发布阶段挡掉很多脏数据。

3. 摘要字段最好显式存在

很多系统喜欢从正文里截前 120 个字当摘要。这个策略对技术文章并不友好，因为正文前面经常是代码块、命令或者引用。显式维护 summary，虽然麻烦一点，但列表页质量会稳定很多。

一个适合博客系统的建模思路

如果项目还是早期，我会推荐这个顺序：

1. 先把 Post 模型建完整。
2. 再补 Category 的一对多关系。
3. 最后再补 Tag 的多对多关系。

原因很简单，博客列表和详情页最先依赖的是文章主体，其次才是分类和标签。这样做，系统能更快跑起来，后面也更容易演进。

小结

Sequelize 真正帮到博客系统的地方，不是替代 SQL，而是让“内容对象该长什么样”这件事更清晰。模型设计阶段多花一点时间，后面的列表、搜索、归档和后台发布都会轻松很多。