从业务需求出发设计表结构:字段、索引、约束、关系,附建表 SQL 与迁移思路。
新功能建表、老库改造、接口数据结构设计。
帮我设计数据库表结构。 【业务】{{业务场景}} 【实体】{{核心实体}} 【查询需求】{{查询需求}} 【数据库】{{数据库}} 输出: 一、实体关系说明:用文字描述一对多/多对多关系(例如一个订单多个书籍,一本书属于一个卖家),标出哪些关系需要中间表。 二、建表 SQL({{数据库}} 语法),每张表包含: - 主键(自增还是业务 ID,说明选择理由) - 业务字段(类型精确:金额用 DECIMAL(10,2)、状态用 TINYINT 或 ENUM) - 时间字段(created_at / updated_at,说明时区处理) - 软删除标记(如果需要,说明查询要带的默认条件) - 外键约束(是否启用,说明在高并发下的取舍) - 字段注释(每个字段一行 COMMENT) 三、索引设计:针对 {{查询需求}} 逐条给索引方案(联合索引的字段顺序及原因),说明哪些查询会走索引、哪些会全表扫。 四、反范式取舍:列出 2-3 个可以冗余的字段(例如订单表存书籍标题快照),说明为什么冗余(历史数据一致性)。 五、约束与校验:唯一约束、枚举值范围、金额非负、状态机允许的流转。 六、容量估算:按日增量估算 1 年数据量,说明什么时候需要分区或归档。 七、常见坑 5 条:金额用 float、时间用字符串、状态字段无注释、忘记加索引、过度设计(过早分表)。 八、种子数据:给 3 条示例 INSERT,方便我立即测试。 要求:不要过度设计,先满足当前查询,演进方案用一段文字说明即可。
小项目用,高并发写入场景常靠应用层保证。
能保数据,但所有查询都要记得带条件,容易漏。