设计可扩展数据库表结构时用：从需求分析到索引、约束…

当你需要为 SQL 或 NoSQL 数据库设计生产级 schema、优化现有表结构或编写可回滚迁移时使用。

适用场景

解决思路

1. 按四阶段流程推进：Phase 1 分析（识别实体与关系、确定读写访问模式、选择 SQL 或 NoSQL）；Phase 2 设计（SQL 规范化到 3NF，NoSQL 选择嵌入或引用，定义主键外键、选择数据类型、添加 UNIQUE/CHECK/NOT NULL 约束）；Phase 3 优化（规划索引策略、对读密集查询考虑反规范化、添加 created_at 与 updated_at 时间戳）；Phase 4 迁移（生成含 up 与 down 的迁移脚本、保证向后兼容、规划零停机部署）。
2. 用命令式工作流迭代：先 `design schema for {domain}` 生成完整 schema，再用 `normalize {table}` 规范化，用 `add indexes for {table}` 优化性能，用 `migration for {change}` 演进结构，最后用 `review schema` 审计。
3. 遵循四条核心原则：按业务领域建模（实体名反映业务概念而非 UI）、数据完整性优先（约束放在数据库层）、按访问模式优化（OLTP 规范化、OLAP 反规范化）、提前规划扩展（索引策略 + 分区方案）。
4. 规范化时逐级检查：1NF 要求原子值、无重复组（禁止 `product_ids = '1,2,3'`，应拆出 order_items 表）；2NF 在 1NF 基础上消除部分依赖（如 order_items 中不应出现 customer_name）；3NF 在 2NF 基础上消除传递依赖（如 customers 中不应由 postal_code 推导出 country，应拆出 postal_codes 表）。
5. 仅在读密集报表、昂贵 JOIN、分析看板场景下反规范化：使用预计算聚合、缓存派生列、物化视图（如 orders 表中冗余 total_amount 与 item_count）。
6. 按用途选择数据类型：字符串用 CHAR(n) 存定长（国家代码）、VARCHAR(n) 存变长（email VARCHAR(255)、phone VARCHAR(20)）、TEXT 存长内容；数值用 TINYINT 存年龄/状态码、SMALLINT 存数量、INT 存 ID/计数、BIGINT 存大 ID/时间戳、DECIMAL(p,s) 存金额、FLOAT/DOUBLE 存科学数据；金额必须用 DECIMAL(10,2)，绝不用 FLOAT；日期用 DATE/TIME/DATETIME/TIMESTAMP 并统一存 UTC；布尔在 PostgreSQL 用 BOOLEAN、MySQL 用 TINYINT(1)。
7. 建立索引策略：始终为外键、WHERE 子句列、ORDER BY 列、唯一约束建索引；按场景选类型（B-Tree 用于范围与等值、Hash 用于精确匹配、Full-text 用于文本搜索、Partial 用于行子集）；复合索引把选择性最高或最常单独查询的列放最前（如 idx_customer_status(customer_id, status) 能服务 customer_id 单独查询，但 status 单独查询用不上）；避免过度索引、列顺序错误、遗漏外键索引。
8. 设计约束：主键按场景选 AUTO_INCREMENT、UUID（分布式系统）或复合主键（联结表）；外键按语义选 ON DELETE 策略（CASCADE 用于依赖数据如 order_items、RESTRICT 用于重要引用、SET NULL 用于可选关系）；使用 UNIQUE、复合 UNIQUE、CHECK（如 price >= 0、discount BETWEEN 0 AND 100）、NOT NULL。
9. 按关系模式建表：一对多用子表外键引用父表；多对多用联结表加复合主键（如 enrollments(student_id, course_id)）；自引用用 manager_id 引用同表 id；多态用分离外键加 CHECK 约束（完整性更强）或 type + id 组合（更灵活但完整性弱）。
10. NoSQL（MongoDB）设计时按因素选择嵌入或引用：一起读取、1:few、文档小、更新少则嵌入；分开读取、1:many、接近 16MB、频繁更新则引用；索引用 db.collection.createIndex 建单字段（unique）、复合、text、2dsphere 地理索引。
11. 编写迁移时遵循最佳实践：始终可回滚、向后兼容、schema 变更与数据变更分离、先在 staging 测试；添加列采用零停机四步（先加可空列 → 部署写入新列的代码 → 回填数据 → 改为 NOT NULL）；重命名列采用五步（加新列 → 复制数据 → 部署读新列代码 → 部署写新列代码 → 删除旧列）；迁移模板用 BEGIN/COMMIT 包裹 UP 与 DOWN 两段。
12. 做性能优化：用 EXPLAIN 分析查询，关注 type: ALL（全表扫描，差）、type: ref（用索引，好）、key: NULL（未用索引）、rows 过高（扫描行多）；避免 N+1 查询，改用单次 JOIN；按场景使用加索引、反规范化、分页、缓存、读副本、分区。
13. 交付前逐项核对验证清单：每表有主键、所有关系有外键约束、每个外键定义 ON DELETE 策略、所有外键有索引、频繁查询列有索引、数据类型恰当（金额用 DECIMAL）、必填字段 NOT NULL、需要处有 UNIQUE、有 CHECK 校验、有 created_at 与 updated_at、迁移脚本可回滚、已在 staging 用生产数据测试。
14. 规避反模式：不要到处用 VARCHAR(255)（按字段合理定长）、不要用 FLOAT 存金额（用 DECIMAL(10,2)）、不要省略外键约束、不要漏建外键索引、不要把日期存成字符串、不要用 SELECT *、不要写不可回滚迁移、不要在无默认值时直接加 NOT NULL（应先加可空、回填、再加约束）。

适用边界 · 注意事项

• 需要针对特定数据库（MySQL/PostgreSQL/SQLite）的方言细节或 ORM（TypeORM、Prisma、SQLAlchemy）集成时，本技能只提供通用模式，需另行查阅对应文档。
• 涉及时间序列、事件溯源、CQRS、多租户等高级架构模式时，本技能仅列为扩展点，未给出具体方案。
• 需要查询性能监控、慢查询告警等运维能力时，本技能只覆盖设计阶段，不含监控落地。