在借助Gemini进行数据库设计讨论时，许多团队发现模型给出的表结构要么过于理想化，要么忽略业务约束。真正有用的做法是把提示词拆成不同维度去问，让模型沿着你的思路做方案权衡，而不是一句话让它“设计数据库”。下面从实体关系、范式与反范式、性能扩展三个角度，梳理可以直接套用的具体问法。
一、实体与关系梳理类问法
数据库设计的第一步是搞清楚有哪些实体、它们之间是什么关系。如果提示词只说“帮我设计用户系统的数据库”，Gemini很容易遗漏边缘业务对象。更具体的问法应当是：请列出电商场景中用户、收货地址、订单、订单项、商品五个实体的属性，并用文字说明它们之间是一对多还是多对多关系，指出哪些外键必须建立。这种问法强迫模型先输出实体清单，再描述关联，方便你检查领域模型是否完整。
另一种实用问法是让Gemini扮演资深DBA做反向确认：假设我们要做一套博客系统，我初步认为用户和文章是一对多、文章和标签是多对多，请指出这种设定在评论、草稿、协同编辑场景下会漏掉哪些实体或关系，并给出修正后的ER描述。通过让它挑错，你能快速发现设计盲区。下面是一段可复用的提示词示例，直接粘贴到Gemini即可：
你是一名数据库架构师。我们的业务是在线教育，核心对象有学生、教师、课程、章节、作业。 请完成以下任务： 1. 列出每个实体的关键字段及类型； 2. 说明学生选课、教师授课、作业提交分别是哪种基数关系； 3. 指出若支持“课程套餐”会新增什么实体或关联。 不要写建表语句，只输出文字分析。
这类问法的优势在于低成本验证领域模型。相比直接要SQL，文字层面的关系梳理更易于产品、开发、测试三方共识。缺点是如果业务本身模糊，模型也会含糊其辞，因此提问时要附上你已有的业务规则，减少它自由发挥的空间。
二、范式与反范式权衡类问法
很多开发者知道范式但不清楚何时该违反。可以让Gemini针对具体场景对比方案：在订单明细报表查询频繁、写操作较少的后台系统中，请对比严格第三范式与适度反范式（将商品名称冗余进订单项）两种设计的优缺点，并说明反范式下更新异常如何规避。这种问法能得到带上下文的取舍建议，而不是教科书式回答。
还可以用假设边界的方式提问：如果我们的评论系统每天新增千万级数据，且展示评论时必须连带用户名和头像，请分析把用户昵称冗余到评论表而非连表查询的理由，并给出冗余字段的更新同步策略。模型通常会建议通过消息队列异步更新，或接受最终一致性。以下是一个对比提问的模板代码，可用于Gemini对话：
prompt = """ 我设计一个物联网设备告警系统。 方案A：告警表只存device_id，设备表存设备名、区域。 方案B：告警表冗余device_name和region字段。 请从写入频率、查询延迟、存储成本三角度对比，并给出B方案下设备改名时的处理代码思路（伪代码即可）。 """
通过这类问法，Gemini输出的不再是“一般要遵循三范式”，而是结合你业务读写比的具体路线。要注意的是，模型可能低估一致性维护成本，所以你在收到建议后，应人工追加一句“如果改名接口每小时调用五万次，B方案是否仍可行”来做压力推演。
三、性能与扩展设计类问法
当表数据量上涨，索引和分片成为焦点。具体问法可以是：用户行为日志表预计三年达二十亿行，查询多按user_id和日期范围，请给出分表键建议、合适索引组合，并解释为什么不要按月单分表。Gemini一般会推荐按user_id哈希加时间分区，并提醒单纯按月分表会导致热用户数据倾斜。
在讨论扩展时，可让其输出可落地的脚本雏形：请写一段PostgreSQL建表语句，包含LIST分区按年份，并在user_id上建BRIN索引，同时用文字说明该索引为何适合时序追加写场景。示例如下：
CREATE TABLE log_2024 PARTITION OF user_log FOR VALUES IN (2024); CREATE INDEX idx_log_user_brin ON user_log USING brin (user_id); -- BRIN适合物理有序追加，用户日志按时间写入故user_id局部有序
这种问法把抽象性能讨论转成带代码的方案，便于直接进测试库验证。不过模型给出的分区阈值往往偏保守，实际分表数量要结合你集群规格调整。整体来看，把提示词从“设计数据库”细化为实体、范式、性能三层具体问法，才能让Gemini真正成为可参与评审的协作者，而非随意吐表的生成器。