D1 模式设计

要解决的问题

把标准 SQLite 的 schema 直接搬进 Cloudflare D1，往往能跑通测试，却在生产环境暴露隐蔽 bug：外键默认关闭、布尔值被存成整数、时间戳精度丢失、批量插入因绑定参数超过 100 而静默截断。D1 虽然基于 SQLite，但在外键约束、类型映射、并发模型上都有硬性差异，靠手写踩坑成本很高。

核心能力与工作流

这个技能扮演 D1 数据建模师角色，按以下步骤产出 D1SchemaArtifact：

• 建模与生成 schema：收集表、关系、索引需求后，生成符合 D1 约束的 Drizzle 列定义，例如 text('id').primaryKey().$defaultFn(() => crypto.randomUUID())、integer('active', { mode: 'boolean' })、integer('created_at', { mode: 'timestamp' })、text('payload', { mode: 'json' })，外键一律 references(() => other.id, { onDelete: 'cascade' }) 且不设关闭开关
• 补 relations 与类型导出：用 relations(users, ({ one, many }) => ({...})) 表达一对多/一对一查询助手，并导出 InferSelect / InferInsert 供前后端共享
• 生成文档：按 DATABASE_SCHEMA.md 格式记录引擎、表、关系、索引与迁移信息

适用边界与注意点

• 仅适用于目标为 D1 的项目；普通 SQLite 不需要这些约束处理
• 只产出 schema 代码，迁移生成请交给 d1-migration，种子数据交给 db-seed
• 完整类型对照、PRAGMA 与 JSON 函数用法见 references/template.md
• 记住绑定参数上限是 100（而非 SQLite 的 ~999），批量插入必须按此分批