数据库与数据表表名规范验证最佳实践

任务目标

• 验证数据库名称和数据表表名是否符合团队规范
• 支持自动修改文件中的表名（默认行为）
• 仅适用于数据库和数据表的名称，不涉及表字段命名

数据库命名规范

格式要求

• 全部使用小写字母
• 不同语义部分之间使用**下划线（_）**分隔
• 命名长度：控制在2-4个语义段

核心原则

• 简洁表意：直接体现数据库的业务归属或用途
• 避免冗余：不包含无意义的缩写或重复字符

数据表表名命名规范

说明：仅验证数据表的表名（table name），不涉及表字段（column/field）命名。

格式要求

• 基本结构：「形容词 + 名词（复数）」
• 全部使用小写字母
• 不同语义部分之间使用**下划线（_）**分隔
• 最后一个名词必须采用英文复数形式

核心原则

• 形容词：体现表的业务属性或范围（如user、order、system）
• 名词：体现表存储的核心数据对象，必须使用复数形式
• 见名知意：整体表意清晰，避免无意义缩写
• 长度控制：控制在3-4个语义段内

补充规则

• 单名词扩展：详细规则见 references/english-plural-rules.md
• 避免过长：user_order_addresses 合理，user_order_shipping_receive_addresses 需简化
• 常见错误与修正：见 references/common-errors.md

文件命名规范（Drizzle ORM 文件）

格式要求：数据库表名 + _table

• 数据库表名必须符合表名规范（复数、小写、下划线）
• 文件名中的表名必须与 pgTable() 函数中的表名一致

示例：

• users_table.ts → pgTable("users", {...})
• user_profiles_table.ts → pgTable("user_profiles", {...})

常见错误：见 references/common-errors.md

验证流程

单个命名验证

识别类型 → 逐项检查 → 结果反馈

批量命名审查

分类整理 → 逐个验证 → 一致性检查 → 汇总报告

文件命名验证与修正

默认行为：直接执行自动修改，除非用户明确说"只检查"、"只建议"、"不修改"、"不要改"等

核心流程：

1. 识别用户意图和上下文（优先级：文件/文件夹路径 → 主动查找 → 只检查）
2. 查找或读取文件
3. 验证文件名（针对 Drizzle ORM 等表定义文件）
4. 识别表名并验证
5. 判断是否修改
6. 执行修改（使用 edit_file，limit=-1）
7. 验证结果并输出报告

完整执行流程和示例：见 references/usage-examples.md

资源索引

• 常见错误与修正：见 references/common-errors.md（何时读取：遇到具体错误类型或需要修正方案时）
• 使用示例：见 references/usage-examples.md（何时读取：需要参考完整执行流程和示例时）
• 英文复数规则：见 references/english-plural-rules.md（何时读取：遇到不确定的英文复数形式时）
• 最佳实践示例：见 best-practice-examples/（何时读取：需要参考 Drizzle ORM 最佳实践代码示例时）

注意事项

• 适用范围：仅验证数据库和数据表的表名，不涉及表字段命名
• 默认行为：提供文件路径或说"数据库/表是否符合规范"时，默认执行自动修改
• 只检查模式：用户说"只检查"、"只建议"、"不要修改"、"不修改"、"不要改"等 → 只检查不修改
• 文件查找策略：
  • 用户提供了文件/文件夹路径 → 只处理指定的，不主动查找其他文件
  • 用户未提供路径 → 使用 glob_file 主动查找相关文件
  • 用户提供文件夹 → 只在该文件夹内查找，不递归到子文件夹（除非明确要求）
• 文件修改原则：
  • 使用 limit=-1 替换所有匹配项
  • 保持原文件格式和缩进不变
  • 修改前读取，修改后验证
  • 提供详细的修改报告，包括文件路径

使用场景

• 新建数据库/表前的表名验证
• 代码审查阶段的表名规范检查
• 团队培训中的规范讲解
• 数据库重构时的表名规范化
• 批量审查现有数据库和数据表表名一致性
• 自动修改文件中的表名（SQL文件、配置文件、代码文件等）——默认行为
• 只检查不修改（用户明确要求时）