数据库字段命名如何方便后续升级

字段风格先稳定，升级才不费力

数据库字段命名看似是建表时顺手定下的小事，但内容类型从文章扩展到视频、资源或 AI 功能时，命名不一致带来的麻烦会成倍放大。早期定下一套规则，后续每张新表都按同一套逻辑走，升级就只是加字段或加表，而不是回头改旧数据。

判断字段命名是否合理，不能只看当前页面能否显示数据。要确认数据从后台表单进入数据库、再从数据库输出到前台页面、最后被权限和 SEO 逻辑读取，整条链路是否顺畅。如果中间任何一环要单独写特例，说明字段设计已经出现偏差。

公共字段的命名约定

个人平台的内容类型通常具备几个共同属性：标题、链接别名、摘要、正文、发布状态、发布时间、删除标记。把这些公共属性用一致的字段名表达，是降低后续维护成本的第一步。

推荐直接使用以下字段：

• title：内容标题，所有类型通用
• slug：URL 别名，用于前台访问地址
• summary：摘要，列表页和分享场景使用
• content_md：Markdown 格式正文，便于统一渲染
• status：发布状态，如草稿、已发布、下线
• published_at：实际发布时间，与创建时间区分
• deleted_at：软删除标记，NULL 表示未删除

status 和 published_at 分开存有实际原因。status 只表示当前状态，published_at 记录真正对用户可见的时间点。假设要做定时发布，只需在到达时间后把 status 改为已发布，同时写入 published_at，不需要额外建任务表。如果后台允许编辑已发布内容并重新定时，也只需更新这两个字段。

deleted_at 采用软删除而不是物理删除，好处是误删后还能恢复，同时保留内容的历史轨迹。查询前台内容时统一加 WHERE deleted_at IS NULL 条件，后台管理列表则可以根据需要选择是否显示已删除记录。

字段拆分与表结构判断

SEO 元数据不建议直接堆在内容主表里。seo_title、seo_description、seo_keywords 这些字段并非所有内容类型都需要，而且不同模块的 SEO 需求可能不同。单独建一张 seo_meta 表，用 content_type 和 content_id 关联到具体内容，既保持主表干净，也方便以后给非内容页面（比如分类页、标签页）挂 SEO 信息。

判断一张表是否需要拆分，可以看字段的使用频率和业务归属。如果某些字段只在特定内容类型下才有值，其他类型下永远为空，就应该考虑拆出去。反过来，如果所有类型都必然用到，就留主表，不要为了拆而拆。

published_at 的默认值不要设为当前时间戳。正确做法是：创建记录时 published_at 为 NULL，当内容真正发布时才写入时间。这样列表页按 published_at 排序时，未发布内容不会混入其中。

PHP 处理逻辑中的常见错误

字段命名统一后，PHP 代码里的处理逻辑也要跟着统一。最容易出错的地方是状态判断和软删除过滤。

```php
// 获取已发布且未删除的内容列表
$sql = "SELECT title, slug, summary, published_at
FROM contents
WHERE status = 'published'
AND deleted_at IS NULL
AND published_at <= NOW()
ORDER BY published_at DESC";
```

这段查询里 published_at <= NOW() 是容易遗漏的条件。如果后台误操作把 published_at 设成了未来时间，前台就会提前看到内容。加上这个条件后，即使时间设置错误，内容也要等到时间到达才显示。

另一个常见错误是在控制器里重复写过滤条件。假设后台列表、前台列表、RSS 输出三处都要查询内容，每处都手写 WHERE deleted_at IS NULL，一旦以后改用其他删除标记，就要改三个地方。正确做法是把查询逻辑封装成模型方法，例如 getPublishedContents()，内部统一处理状态和软删除条件，外部调用时不需要关心细节。

容易忽略的检查点

字段命名规范执行一段时间后，回头检查时重点看以下几处：

后台可维护性。前台展示正常不代表后台能正常编辑。检查后台表单是否完整映射了所有需要维护的字段，特别是 slug 是否允许手动修改、修改后旧链接是否需要做重定向。

权限与日志。内容表通常会有创建者、最后修改者字段。如果一开始没规划，后期要加操作日志就会很被动。建议在内容主表预留 created_by 和 updated_by，即使当前只有一个用户，也先按规范建好。

错误提示。接口和后台操作必须返回明确的错误信息。比如 slug 重复时，不能只返回“保存失败”，要告诉用户哪个字段冲突、当前值是什么。PHP 端可以用 try-catch 捕获数据库异常，把错误信息转换成用户能理解的提示。

软删除的连带处理。删除一篇内容时，它的 SEO 记录、标签关联、访问统计是否需要同步处理？如果全部保留，查询时要做关联过滤；如果物理删除，要注意外键约束。这个决定要在建表时就想清楚，而不是等数据量大了再补。

实际项目中的落地方式

把上述规则落到实际项目中，建议按以下顺序操作：

先梳理现有内容类型，列出所有公共字段和各自独有的字段。公共字段统一命名，独有字段单独建表或加前缀区分。然后统一控制器层的查询入口，所有内容读取都经过同一个方法，避免散落的原生 SQL。最后检查后台表单和列表页，确认每个字段都有对应的维护入口。

对于以后可能新增的模块，比如标签、访问统计、版本记录，不要一开始就全部建表，而是保持主表结构稳定，等确实需要时再新增关联表。新增表不影响已有表结构，这是字段命名规范带来的最大好处。

涉及私有数据或敏感信息时，只记录处理方式，不把具体内容写入公开文档。这样既能保证项目可维护，也不会泄露不必要的信息。