170 lines
6.5 KiB
Markdown
170 lines
6.5 KiB
Markdown
---
|
||
tags: []
|
||
aliases:
|
||
- 🛡️ AI 辅助数据建模通用 SOP (v1.0)
|
||
date created: 星期日, 十二月 7日 2025, 9:16:59 晚上
|
||
date modified: 星期二, 十二月 9日 2025, 11:27:28 晚上
|
||
---
|
||
|
||
# 🛡️ AI 辅助数据建模通用 SOP (v1.0)
|
||
|
||
**核心理念:**
|
||
|
||
1. **DBA 思维优先:** 永远先设计 SQL (Source of Truth)，再生成代码 (ORM)。
|
||
2. **可视逻辑验证:** 在写代码前，必须通过 ER 图确认业务逻辑闭环。
|
||
3. **对抗性评审:** 利用 AI 的多重人格（架构师/攻击者）自我找茬。
|
||
|
||
---
|
||
|
||
## 📋 准备工作：定义变量
|
||
|
||
在使用以下 Prompt 前，请先在脑海或记事本中替换以下占位符：
|
||
|
||
- `{技术栈}`: 例如 PostgreSQL 15, MySQL 8.0, TiDB
|
||
- `{ORM框架}`: 例如 GORM (Go), TypeORM (Node), Hibernate (Java)
|
||
- `{业务模块}`: 例如 用户中心, 订单交易, 库存管理
|
||
- `{具体需求}`: 粘贴你的 PRD 片段或业务规则描述
|
||
|
||
---
|
||
|
||
## 阶段一：上下文注入与规范确立 (Context & Standards)
|
||
|
||
**目的:** 确立“宪法”。防止 AI 自由发挥导致命名风格混乱或忽略关键字段。
|
||
|
||
### 🤖 通用 Prompt (复制使用)
|
||
|
||
```markdown
|
||
你现在是我的 **Senior DBA (首席数据库管理员)** 和 **后端架构师**。
|
||
我们将基于 `{技术栈}` 和 `{ORM框架}` 进行 `{业务模块}` 的数据库设计。
|
||
|
||
在开始具体设计前，请牢记并遵守以下 **[设计宪法]**:
|
||
|
||
1. **命名规范:**
|
||
- 表名: 复数形式，snake_case (如 `user_orders`).
|
||
- 字段: snake_case (如 `is_verified`).
|
||
- 索引: `idx_表名_字段` (普通), `uniq_表名_字段` (唯一).
|
||
- 外键: `fk_本表_关联表`.
|
||
|
||
2. **基础字段 (Base Model):**
|
||
- 所有业务表必须包含: `id` (主键), `created_at`, `updated_at`.
|
||
- 需要软删除的表必须包含: `deleted_at`.
|
||
- 乐观锁(如有需要): `version`.
|
||
|
||
3. **类型约束:**
|
||
- 金额: 严禁使用 Float/Double，必须使用 `DECIMAL` 或 `BigInt` (存分).
|
||
- 枚举: 尽量在应用层处理，数据库存 `SmallInt` 或 `String`，避免使用 DB 级 ENUM.
|
||
- 时间: 统一使用带时区的 `TIMESTAMPTZ` (PostgreSQL) 或 `DATETIME`.
|
||
|
||
4. **安全与性能:**
|
||
- 必填字段显式标记 `NOT NULL`。
|
||
- 外键必须加索引。
|
||
- 物理外键约束建议使用 `ON DELETE RESTRICT` 防止误删，除非明确需要级联。
|
||
|
||
收到请回复：“DBA 模式已就绪，请提供具体业务需求。”
|
||
```
|
||
|
||
---
|
||
|
||
## 阶段二：概念验证 (Conceptual Modeling - ER Diagram)
|
||
|
||
**目的:** 宏观排雷。通过可视化图表快速识别逻辑错误（如：1 对多搞成了多对多，或者环状依赖）。
|
||
|
||
### 🤖 通用 Prompt (复制使用)
|
||
|
||
```Markdown
|
||
请根据以下 `{具体需求}`，绘制 **Mermaid 格式** 的 ER 关系图 (Entity Relationship Diagram)。
|
||
|
||
**需求输入:**
|
||
"""
|
||
(在此处粘贴你的业务逻辑，例如：一个用户可以有多个角色，文章必须属于一个分类…)
|
||
"""
|
||
|
||
**绘图要求:**
|
||
1. 展示实体(Entity)及其核心属性。
|
||
2. 精准标注关系基数 (Cardinality):
|
||
- `||--o{` (1 对多)
|
||
- `}|--|{` (多 对 多，需画出中间表)
|
||
- `||--||` (1 对 1)
|
||
3. 在图表下方简要说明关键关系的业务含义。
|
||
```
|
||
|
||
---
|
||
|
||
## 阶段三：物理建模 (Physical Schema - SQL DDL)
|
||
|
||
**目的:** 产出真理。这是最关键的一步，SQL DDL 定义了数据的最终形态。
|
||
|
||
### 🤖 通用 Prompt (复制使用)
|
||
|
||
```Markdown
|
||
ER 图确认无误。请生成 **生产级 (Production-Ready) 的 SQL DDL 建表脚本**。
|
||
|
||
**执行要求:**
|
||
1. **完整性:** 包含 `CREATE TABLE`, `CREATE INDEX`, 以及必要的 `COMMENT ON` 语句。
|
||
2. **字段细节:**
|
||
- 针对 JSON 数据使用数据库原生类型 (如 PG 的 `JSONB`)。
|
||
- 针对长文本使用 `TEXT`。
|
||
- 默认值 `DEFAULT` 处理到位 (如 `DEFAULT 0`, `DEFAULT FALSE`, `DEFAULT NOW()`).
|
||
3. **约束定义:**
|
||
- 明确定义 `PRIMARY KEY`。
|
||
- 显式定义 `CONSTRAINT` 名称 (便于排错)。
|
||
4. **索引策略:**
|
||
- 除了主键，请根据业务查询场景（如“按状态查询”、“按时间范围排序”）主动添加辅助索引。
|
||
- 解释每个索引添加的理由。
|
||
|
||
请直接输出 SQL 代码块。
|
||
```
|
||
|
||
---
|
||
|
||
## 阶段四：代码映射 (Code Generation - ORM Struct)
|
||
|
||
**目的:** 翻译。将 SQL 完美映射为代码，利用 AI 自动处理繁琐的 Tag。
|
||
|
||
### 🤖 通用 Prompt (复制使用)
|
||
|
||
```Markdown
|
||
基于上述生成的 SQL 脚本，请编写对应的 `GORM (Go)` 模型代码 (Entity/Model)。
|
||
|
||
**代码要求:**
|
||
1. **Tag 映射:** 完整包含 DB 列名映射、主键定义、默认值定义。
|
||
- (若为 GORM): 使用 `gorm:"column:xyz;type:…"`.
|
||
2. **JSON 序列化:**
|
||
- 所有字段添加 `json:"camelCaseName"`.
|
||
- **敏感字段** (如密码、盐值) 必须设为 `json:"-"` 以防接口泄露。
|
||
3. **类型安全:**
|
||
- 数据库允许 NULL 的字段，在代码中请使用 指针类型 (如 `*string`) 或 专用 Null 类型 (如 `sql.NullString`)。
|
||
4. **文件结构:** 不需要 `gorm.Model` 继承，请显式写出字段，以保证对 JSON Tag 的控制权。
|
||
|
||
请输出 Go/Java/TS 代码块。
|
||
```
|
||
|
||
---
|
||
|
||
## 阶段五：红队测试与评审 (Critique & Optimization)
|
||
|
||
**目的:** 找茬。让 AI 模拟极端的架构师，攻击当前设计，发现隐患。
|
||
|
||
### 🤖 通用 Prompt (复制使用)
|
||
|
||
```Markdown
|
||
现在，请切换角色为 **Google 首席架构师 (Principal Architect)**。
|
||
请对上述 SQL 设计进行 **“红队测试” (Red Teaming)** 评审。
|
||
|
||
**评审维度:**
|
||
1. **扩展性瓶颈:** 如果单表数据量达到 5000 万行，目前的索引设计是否会失效？哪个查询会最慢？
|
||
2. **数据一致性:** 是否存在业务逻辑上需要事务保证，但当前 Schema 难以支持的场景？
|
||
3. **反范式建议:** 是否有过度规范化导致查询需要 Join 太多表？是否建议增加冗余字段？
|
||
4. **边缘情况:** `NULL` 值的处理是否会在聚合查询时导致 Bug？
|
||
|
||
请列出 top 3 风险点，并给出具体的 **优化建议** (如：修改索引、增加冗余字段、修改类型)。
|
||
```
|
||
|
||
---
|
||
|
||
### 💡 使用小贴士
|
||
|
||
1. **不要一次性发完:** 强烈建议**分步执行**。AI 的上下文窗口虽然大，但分步确认能极大提高准确率。
|
||
2. **迭代修改:** 在“阶段三”生成 SQL 后，如果你发现不满意，手动修改 SQL，然后把修改后的 SQL 发给 AI 进入“阶段四”。**永远以 SQL 为准**。
|
||
3. **保留对话:** 把这个对话保留为一个独立的 Session，后续增加字段时，回到这个 Session 继续操作，保持上下文连贯。
|