database-schema-designer

# 数据库架构设计器 设计内置最佳实践的生产就绪数据库架构。 --- ## 快速开始 只需描述您的数据模型： design a schema for an e-commerce platform with users, products, orders 您将获得一个完整的 SQL 架构，如下所示： sql CREATE TABLE users ( id BIGINT AUTO_INCREMENT PRIMARY KEY, email VARCHAR(255) UNIQUE NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE orders ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL REFERENCES users(id), total DECIMAL(10,2) NOT NULL, INDEX idx_orders_user (user_id) ); **请求中应包含的内容：** - 实体（用户、产品、订单） - 关键关系（用户拥有订单，订单包含项目） - 规模提示（高流量、数百万条记录） - 数据库偏好（SQL/NoSQL） - 如果未指定，默认为 SQL --- ## 触发器 | 触发器 | 示例 | |---------|---------| | `design schema` | "为用户身份验证设计架构" | | `database design` | "多租户 SaaS 的数据库设计" | | `create tables` | "为博客系统创建表" | | `schema for` | "库存管理的架构" | | `model data` | "实时分析的数据建模" | | `I need a database` | "我需要一个用于跟踪订单的数据库" | | `design NoSQL` | "为产品目录设计 NoSQL 架构" | --- ## 关键术语 | 术语 | 定义 | |------|------------| | **规范化 (Normalization)** | 组织数据以减少冗余 (1NF → 2NF → 3NF) | | **3NF** | 第三范式 - 列之间没有传递依赖 | | **OLTP** | 在线事务处理 - 写密集型，需要规范化 | | **OLAP** | 在线分析处理 - 读密集型，受益于反规范化 | | **外键 (FK)** | 引用另一个表主键的列 | | **索引 (Index)** | 加快查询速度的数据结构（以牺牲写入速度为代价） | | **访问模式 (Access Pattern)** | 应用程序如何读写数据（查询、连接、过滤） | | **反规范化 (Denormalization)** | 有意复制数据以加快读取速度 | --- ## 快速参考 | 任务 | 方法 | 关键考量 | |------|----------|-------------------| | 新架构 | 首先规范化至 3NF | 领域建模优于 UI | | SQL vs NoSQL | 访问模式决定 | 读/写比例很重要 | | 主键 | INT 或 UUID | 分布式系统使用 UUID | | 外键 | 始终约束 | ON DELETE 策略至关重要 | | 索引 | 外键 + WHERE 列 | 列顺序很重要 | | 迁移 | A