db-naming

db-naming (M7)

命名是架构的文档：一致、可预测的标识符能让联接一目了然，并减少 ORM 和数据库引擎中常见的引号与大小写错误。它的权重较低（命名类别，设计轴）——确实重要，但绝不会是重点。本模块属于设计轴，且永远不会设定上限。

检查内容

• 大小写 / 单复数一致性：同一架构中混用 snake_case 和 camelCase，或表名同时使用单数和复数（user、orders、OrderItem）——选定一种并保持一致。
• 保留字与大小写折叠陷阱：标识符是 SQL 保留字（user、order、group、select），或依赖大小写（加引号的 "User"）——Postgres 会将未加引号的名称折叠为小写；MySQL 则取决于文件系统和大小写配置。混用引号会导致「relation does not exist」错误。
• 外键命名：外键列未遵循可预测的 <referenced>_id 模式，导致联接关系不够直观。
• 布尔值命名：布尔值名称未使用 is_/has_/can_ 前缀，或使用了会反转逻辑的否定名称（not_active）。
• 含糊 / 有歧义的名称：data、info、value、flag、temp、col1、没有术语表解释的缩写，或未以 _at 结尾的时间戳名称。

轴与严重性

• 轴：设计；严重性几乎总是低，分级应诚实。
• 未加引号的保留字标识符导致跨引擎问题：严重性 2–3，warn。
• 整个架构的大小写 / 单复数不一致：严重性 2，warn，fixable: proposed（重命名的影响范围很大——绝不要设为 auto）。
• 含糊的列名 / 缺少 _at 后缀：严重性 1，warn。
• M7 永远不会封顶任何分数；它是权重最低的设计类别。

Tier-0 静态检查

通过 scripts/parse-schema.mjs 解析 DDL/快照：统计标识符的大小写风格和表名的单复数形式；根据各引擎的保留字列表匹配标识符；检查外键列是否符合 <table>_id 模式；标记未使用 is_/has_/can_ 前缀的布尔列以及含糊的名称。这完全是静态检查，且具有 directional 性质。

Tier-1 验证查询

确认实时标识符清单及引号使用情况：

-- $DATABASE_URL, read-only
SELECT table_name, column_name FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog','information_schema')
ORDER BY table_name;   -- inspect casing/plurality/reserved words across the real catalog

发现

按 schema/finding.schema.json 输出。示例：

• M7.schema.mixed_casing — 架构中混用了 snake_case 和 camelCase 标识符（严重性 2，warn，轴 design，fixable: proposed）。
• M7.user.reserved_word_table — 名为 user 的表需要加引号，且会导致未加引号的引用出错（严重性 2，warn，轴 design）。
• M7.accounts.active_boolean_unprefixed — 布尔值 active 未命名为 is_active（严重性 1，warn）。 每条发现：evidence.observed 原样引用标识符；verification.reproduce 是上述可运行查询（method: ddl_parse / schema_introspect）；expected_impact 按等级划分（通常为 low），并附带 directional 置信度及理由。

诚实性

• 命名问题只是建议性的润色——绝不要让它们主导报告，也不要暗示存在功能缺陷。
• 重命名具有破坏性，会导致应用代码 / 迁移出错；建议应标记为 proposed/advisory，绝不要标记为 auto。
• 保留字和大小写折叠行为因引擎而异；每条发现都应限定到检测到的引擎，不要声称规则普遍适用。