Entity Framework ORM 框架，获取最近 30 天每日分别的订单数量最佳实践是什么？

[rv54ntjwfm3ug8]

数据库保存的是下单时间戳，想到两种思路：

1. 获取最近 30 天全部订单的时间，然后遍历进行计数，只需查询一次数据库。
2. 用最近 30 天每天的起止时间戳查询数据库进行计数，需要查询 30 次数据库。

哪种方案更好一些，为什么？如果数据库还有保存下单日期（ 2000-01-01 文字形式，非时间戳）会不会是不同的结果？

[hard2reg]

用时间戳筛选过滤再 count 很方便啊

[hard2reg]

```sql
select order_date, count(order_id) from t_orders where order_day between curdate() and subdate(curdate(), interval 30 day) group by order_date;
```

[hard2reg]

select order_date, count(order_id) from t_orders where order_date between curdate() and subdate(curdate(), interval 30 day) group by order_date;

之前写错了。。。

[robin700]

如果订单量大不建议走数据库，非常慢，我目前用每日定时统计，根据日统计数据，再汇聚周月季年
，整体上速度很快

[IvanLi127]

我觉得这个查询要么用高级写法去构造一个统计的 SQL ，要么直接传 SQL 查。
楼主的两种方案没什么区别，数据量小的话都行，数据量大的话需要分块查询。如果继续按楼主的思路，我建议可以考虑 id 作为游标，按时间倒序，每次查 n 条。查到不符合条件的就停止。
如果你的时间戳可以直接 distinct ，并且有索引，那还是 SQL 查吧。

[FLYROUTER]

单量大的话直接使用 redis 作原子计数器

[thtznet]

这个屈居于你的需求是领域计算所需还是数据分析所需，如果是领域计算所需，用 ORM 没问题，如果是独立的数据分析所需，建议做数仓，不要放在业务层里。

[adoal]

如果是淘宝这种级别的一互大场景，你需要考虑的不只是这两个操作（我觉得称为两个“方案”用词太豪华了）的技术细节差异，如同前面几楼说的，可能需要做架构设计先。
如果是普通的小规模系统，你是一个新手，只是做一个普通的简单查询……那么，建议先学好 SQL ，理解关系数据库。ORM 只是把人肉写 SQL 换成编程语言这一侧的书写方式而已。

[idblife]

现在的程序员连 sql 都不会了吗？

[yikyo]

ef 也有 groupby 吧？然后看数据的 length 就能得到了

[Rocketer]

不知道是从何开始，国内很多数据库设计的时间字段都是长整型时间戳。问过很多人也不知道为什么，只知道大家都这么干。

日期型字段怎么你们了？为什么不用呢？各种计算都方便。就楼主这需求，用 Linq 直接 groupb 很简单。

sourceList
.GroupBy(x => x.dateTime.Date)
.Select(x => x.Count())
.ToList()

完结，撒花

[sunhelter]

你可以定时任务生成报表，去报表里拿

[beginor]

@Rocketer 时间戳也是可以的这样做，除以一个整数就行了

[dotw2x]

2 的话为什么会查询 30 次呀,代码传入今天和三十天前的时间,固定了查询范围,直接 group by 一次就能出结果了吧

[xuanbg]

sql 不会写，linq 也不会写么。。。天天要用的东西不学，尽学没用的。。。

[xuanbg]

@Rocketer 因为日期类型会有时区问题。。。其实只要服务器不在不同时区，就完全没问题。很多人就是知其然不知其所以然，只会人云亦云。大多数人不肯探究问题，又怕麻烦，倒也可以理解。

[lyy16384]

@beginor #13 加除法不走索引

[Rocketer]

@xuanbg 呃！时区问题肯定不是不用日期型的原因。美国不像中国是统一时区，硅谷的程序员天天都要与时区打交道，但日期型的使用却很普及。

事实上很多数据库内部对日期型数据也是存时间戳，各种日期运算（加减、时区等）还是由日期类实现的。只是国内流行直接存时间戳，然后手动运算。