餐厅评论系统数据库设计：复合主键还是自增主键？

针对你提到的「用户仅能为每家餐厅提交一次评论」的业务场景，两种主键方案各有优劣，结合小型项目的特点，具体分析如下：

复合主键（UserId + RestaurantId）的适用场景与优势 #

• 天然满足业务约束：直接通过主键强制「同一用户对同一餐厅只能有一条评论」的规则，无需额外添加唯一约束，减少数据库冗余配置。
• 业务语义明确：主键本身就体现了评论与用户、餐厅的关联关系，查看表结构时能快速理解数据逻辑。
• 查询性能适配：如果日常查询经常需要同时根据用户和餐厅筛选评论，复合主键的组合索引能直接命中查询，性能表现更优。

复合主键的潜在问题 #

• 外键关联繁琐：如果后续有其他表需要关联评论表，需要同时存储UserId和RestaurantId两个字段，相比单主键会增加少量存储和代码复杂度。
• ORM适配成本：部分ORM框架对复合主键的配置和关联查询支持不如单主键顺畅，需要额外编写一些适配代码，但主流框架（如MyBatis、EF Core）都能处理这类场景。

自增主键的适用场景与优势 #

• 操作简洁性：单主键在ORM操作、数据关联、代码逻辑处理上更直观，减少多字段主键带来的配置和编码工作量。
• 业务扩展性：如果未来业务规则调整（比如允许用户对同一家餐厅追加评论），只需要修改唯一约束，无需改动主键结构，灵活性更高。
• 索引效率：单主键的索引体积更小，插入、查询的性能理论上略优，但小型项目数据量有限，这种差异几乎可以忽略。

针对小型项目的建议 #

如果能确定「用户每家餐厅仅一次评论」的业务规则长期不会变更，复合主键是完全可行的最佳选择——既贴合业务逻辑，又省去额外约束配置。如果担心未来业务调整，或者觉得复合主键在ORM中配置麻烦，也可以选择「自增主键 + (UserId, RestaurantId)唯一约束」的组合，既保证业务约束，又保留扩展性。

内容的提问来源于stack exchange，提问作者Wilson Silva