Database Schema Designer 是一个数据库架构设计技能，主要用于从业务需求、实体-关系图或现有应用代码出发，设计规范化的关系型数据库架构。其产出为 PostgreSQL 或 MySQL 的 DDL，包含合适的数据类型、约束、索引和关系，默认遵循 3NF，并在性能需要时进行策略性反规范化。
用途方面，该技能面向数据库架构设计与迁移场景，帮助把业务领域中的实体与关系转化为可执行的表结构定义。它既支持全新设计，也支持从现有应用模型或类反向推导架构。
主要能力包括：从业务需求中识别实体（名词）并对应为表，列出每个实体的属性并区分必填与可选；定义主键，优先使用 BIGSERIAL（PostgreSQL）或 BIGINT AUTO_INCREMENT（MySQL）作为代理键，分布式系统或将 ID 暴露在 URL 中时可使用 UUID（gen_random_uuid()），真正不可变且唯一的自然键（如 ISO 国家代码、IATA 机场代码）也可接受；按第三范式进行规范化，包括消除重复组、去除部分依赖和传递依赖，并为独立变化的值抽取查找表；定义表间关系，涵盖一对多（在“多”方添加外键）、多对多（建立含两个外键的连接表并使用复合主键）和一对一（添加带 UNIQUE 约束的外键，或合并为单表）；选择精确的数据类型，如金额用 NUMERIC(12,2) 或以整数存储分（禁用 FLOAT/DOUBLE），时间戳用带时区的 TIMESTAMPTZ，日历日期用 DATE，状态字段用带 CHECK 约束的 VARCHAR(20) 或 ENUM，邮箱用 CITEXT 或 VARCHAR(254) 加 CHECK，灵活属性用 JSONB；为每张表添加标准列 created_at、updated_at（配触发器自动更新）和用于软删除的 deleted_at（配 WHERE deleted_at IS NULL 的部分索引）；定义约束，包括 NOT NULL、UNIQUE、CHECK 以及带相应 ON DELETE 行为（CASCADE、SET NULL 或 RESTRICT）的外键；根据预期查询模式设计索引，如外键列索引、高选择性 WHERE 列的 B-tree 索引、全文搜索列的 GIN 索引、按最常见多列过滤模式排列的复合索引（最左列在前）；在 3NF 导致查询过于复杂时进行策略性反规范化，例如物化视图、带触发器更新的冗余计数列、用于灵活元数据的 JSON 列。
使用方式上，技能会按依赖顺序（被引用表在前）生成完整的 DDL 脚本，包括 CREATE TABLE 语句，随后是索引、触发器和查找表的种子数据。输出内容包括：按可执行顺序排列的完整 DDL 脚本（含 CREATE TABLE、约束、索引和触发器）；列出所有表、列、类型和关系的实体-关系描述；说明各索引支持哪些查询模式的索引策略文档；用于国家、状态、类别等查找表或引用表的种子数据脚本；以及与项目迁移框架兼容的迁移文件。
前置条件包括：业务领域需求或可推导架构的现有应用模型/类；用于测试 DDL 的 psql 或 mysql CLI；目标数据库引擎与版本（决定可用的数据类型和特性）；用于容量和索引决策的预期数据量与查询模式；多租户要求（共享架构、每租户独立架构或每租户独立数据库）。
适用场景的示例包括：电商架构（customers、addresses、products、categories 经 product_categories 的多对多、orders、order_items、payments；金额用 NUMERIC(12,2)；customers 和 products 软删除；products.search_vector 上的 GIN 全文索引；orders 上 (customer_id, created_at DESC) 复合索引用于订单历史页）；带行级安全的多租户 SaaS 架构（每表含 tenant_id 并外键指向 tenants，通过行级安全策略实现隔离，复合索引以 tenant_id 开头）；事件溯源架构（events 表以 (aggregate_id, sequence_number) 为复合主键，含 event_type、payload JSONB、created_at，另设 snapshots 表保存定期物化状态，仅追加、不执行 UPDATE 或 DELETE）。
限制与注意事项方面，资料列出的常见错误及处理包括：循环外键依赖会导致无法按顺序建表，可在两表创建后用 ALTER TABLE ADD CONSTRAINT 添加约束，或重构以连接表消除循环；过度规范化会造成大量 JOIN，可对低基数、少变化的查找值反规范化，状态字段用 ENUM 而非独立表；NUMERIC 精度溢出时可提高精度，如用 NUMERIC(15,2) 或对需要亚分精度的货币用 NUMERIC(19,4)；架构过于僵化难以演进时可用 JSONB 列或 EAV 模式，并从一开始规划架构演进；外键列缺少索引会导致顺序扫描，需始终为外键列建索引（PostgreSQL 不像 MySQL InnoDB 那样自动为外键建索引）。具体平台与收费信息暂未提供。