在关系表中存储view_rank排名字段是否为不良实践？

首先直接回应你的核心疑问：存储view_rank字段并非绝对的不良实践，但在大多数业务场景下，我并不推荐这么做，原因和适配你需求的替代方案我给你详细拆解：

为什么存储view_rank可能是个“坑”？ #

主要问题集中在数据一致性维护成本上：

• 当view字段更新时（比如用户浏览项目触发view+1），你必须同步更新view_rank，否则排名会和实际浏览量完全脱节。如果是实时更新，每次view变化都要重新计算所有项目的排名——10万条数据的话，这个计算成本反而可能比查询时用窗口函数更高；
• 如果用定时任务批量更新排名，两次任务间隔内的排名是不准确的，对于有实时性要求的场景（比如热门项目榜单），用户会看到过期数据，影响体验；
• 额外的存储和更新逻辑会增加系统复杂度，比如要处理并发更新时的竞态问题，避免排名计算出现错误。

你的需求如何满足？（不用写原生SQL+兼顾10万条数据性能） #

1. 主流ORM都支持窗口函数，不用放弃ORM #

你担心不存储字段就必须写原生SQL，但其实大部分现代ORM（比如Django、MyBatis-Plus、Hibernate等）都已经支持窗口函数的封装，完全可以用ORM语法生成排名。举个Django的实现例子：

from django.db.models import F, Window
from django.db.models.functions import Rank

# 给Item模型生成view_rank排名，按view降序排序
items = Item.objects.annotate(
    view_rank=Window(
        expression=Rank(),
        order_by=F('view').desc()
    )
).order_by('view_rank')

其他ORM比如Hibernate可以用@Formula或Criteria API实现类似逻辑，MyBatis可以在XML映射文件中嵌入窗口函数片段，不用完全手写原生SQL。

2. 10万条数据用窗口函数性能没你想的差 #

只要给view字段建立降序索引，数据库优化器会直接利用索引排序计算排名，无需全表扫描。MySQL 8.0+、PostgreSQL、SQL Server等主流数据库，处理10万条数据的RANK()计算，耗时通常在毫秒级，完全可以满足业务需求。

3. 折中方案：用物化视图替代存储字段 #

如果你的业务对查询性能要求极高，且能接受排名有一定延迟（比如5分钟或1小时刷新一次），可以用数据库物化视图预计算排名：

• 创建物化视图包含item_id、view、view_rank字段，通过数据库定时任务或应用层调度任务定时刷新；
• 在ORM中把物化视图当成普通模型查询，既不用维护表字段，又能享受预计算的性能优势。

什么时候适合存储view_rank？ #

如果你的业务满足以下所有条件，可以考虑存储：

• 排名更新频率极低（比如每天仅更新一次）；
• 对排名的实时性要求极低；
• 项目数量不会快速增长（避免排名计算的成本随数据量膨胀而飙升）。

内容的提问来源于stack exchange，提问作者Diego Alves