Django单Company模型含200字段的弊端及查询性能疑问

为什么不建议用单一200字段的Company模型 #

• 代码维护成本爆炸：200个字段堆在一个模型文件里，代码会臃肿到难以阅读和修改。后续找字段、改逻辑、查问题都要花费大量时间，团队协作时还容易出现代码冲突。
• 违反数据库设计范式：把所有业务模块的字段塞进同一张表，会造成数据冗余，比如财务相关的多个字段对应的业务逻辑分散在各处，难以统一管理。
• 前后端处理都麻烦：前端要渲染200个字段的表单，加载慢、用户体验极差；后端写表单验证、序列化逻辑时，代码量翻倍，出错概率也直线上升。
• 扩展性不足：后续要给某个业务模块加字段或改逻辑，必须动整个Company模型，牵一发而动全身，功能迭代的风险极高。

加载QuerySet时的性能权衡 #

单一模型的性能问题 #

• 查询时会默认加载所有200个字段，哪怕你只需要其中几个基础字段，会浪费大量数据库带宽和服务器内存，查询速度明显变慢。就算用only()/defer()指定字段，写起来繁琐且容易出错。
• 表字段过多会导致数据库存储开销增大，索引设计也会变得复杂，复合索引的维护成本极高，还可能拖累常规查询的效率。

拆分模型的性能优势 #

• 默认查询主模型（如Company）时，不会加载关联的一对一子模型数据（Django惰性加载特性），只有访问关联属性时才会触发额外查询，按需加载更高效。
• 如果需要一次性获取关联数据，用select_related()就能执行一次联表查询，性能和单一模型查全字段差不多，但能灵活选择加载哪些业务模块的数据。
• 每个子模型可以针对自身业务字段单独设计索引，查询特定模块数据时，索引命中率更高，查询速度更快。
• 缓存更精准：可以只缓存某个业务模块的数据，不用缓存全量字段，节省缓存空间的同时，也能提升缓存的命中率。

内容的提问来源于stack exchange，提问作者Daniel Johnson