数据库 Schema 设计提示词

何时使用

当你需要设计关系型数据库 Schema，并且希望获得一个具体可落地的起点，而不是空泛的实体列表时，请使用此提示词。在将生成的结果应用于生产环境之前，请先将虚构的业务细节替换为你自己已确认的业务规则。

提示词内容

## 角色
扮演一名后端数据库架构师。在运用专业判断的同时，确保所做的技术决策对中级软件工程师而言清晰易懂。

## 上下文
KiteFleet 运营着一项多租户设备租赁服务。客户按天或按周租赁重型机械。系统必须跨仓库跟踪库存、包含多项商品的客户预订、押金以及维护检查记录。处于有效检查状态的设备不得出租。KiteFleet 使用 PostgreSQL 16。

## 目标
设计一个规范化的关系型数据库 Schema，防止重复预订，记录资产的状态流转，并将客户账单与预订历史记录解耦。

## 目标受众
主要受众是后端工程师。请确保交付成果可直接用于编写数据迁移脚本，并提供足够的技术上下文来说明数据类型和索引决策的合理性。

## 需求
提供规范的 PostgreSQL DDL；包含主键、外键和列约束的表定义；状态枚举类型；防止重叠预订的部分索引或唯一索引；以及对核心实体间关系基数的简要说明。

## 约束条件
不得引入外部微服务、事件流或文档型存储。严格使用 PostgreSQL 中的关系表进行设计。除标准货币余额字段外，不要擅自设计计价公式或支付网关集成。清晰陈述所有规范化假设。

## 语气与风格
准确、地道、偏技术化。优先使用显式约束命名、标准 SQL 规范和 snake_case 命名法。针对非显而易见的约束提供简要的行内注释。

## 输出格式
首先在专属代码块中展示 PostgreSQL DDL 脚本。随后提供详细说明实体关系的表摘要。最后附上索引设计原理表，以及一份需要应用层进行强制校验的边界情况简要清单。

## 避免事项
避免对受限状态使用宽泛的 TEXT 类型、遗漏外键级联规则、在未考虑索引的情况下使用软删除机制，以及在缺乏性能依据的情况下滥用通用 UUID 键。

## 成功标准
工程师能够无语法错误地运行该 DDL，理解系统如何阻止重叠预订，并能验证维护状态确实可以阻止设备租赁排期。

## 澄清问题
仅在缺失的 Schema 边界会改变表范式时，才提出最多三个针对性问题。否则，直接基于该场景继续设计，记录各项假设，并着重说明生产环境下的技术权衡。

为什么它行之有效

• 该场景定义了具体的领域逻辑（仓库、重叠租赁、维护锁定），而非抽象的 CRUD 模型。
• 需求直接要求提供生产就绪的 DDL 和并发保护机制，而不是简单的实体关系图。
• 约束条件将设计重心牢牢锁定在核心事务完整性上，避免过早引入分布式架构。
• 成功标准确保生成的代码可以直接运行，并切实强制执行场景中的业务规则。

定制为你专属的内容

使用 PromptDeck 构建量身定制的版本，只需将虚构场景替换为你自己的上下文、受众和约束条件即可。保留验证步骤，以确保最终产出切实反映你的已知业务需求。