我一直在考虑/研究与ORM工具一起处理实体日期的最佳方法。目前我正在使用带有MySQL驱动程序的Doctrine2（php 5.3）（如果有人需要知道）。
所以我的情况如下：我有一个跟踪协作分包商的WorkOrders及其发票的系统。因此，WorkOrder可能会有相同/不同的分包商提交的大量发票，这些发票将在给定的支付期间汇总。这笔款项将支付给分包商。我的问题是，处理特定支付期/或任何日期范围的发票的最佳方法是什么？作为一个例子，我有一个表格，显示一年中每个星期的每个分包商的总数，但我也显示一个月的总数等。此外，我有一个日历视图，显示按天和周汇总的相同发票。
目前我传递一个日期范围（fromDate / thruDate）以及一个配置为迭代结果集的类，并根据不同的标准组合集合，例如聚合结果的时间单位和计算器来处理总计基于用户角色和/或发票类型的发票。到目前为止，这种方式似乎非常灵活，但是我关注的是获取10,000个发票的性能影响，使用doctrine水合对象，迭代结果集，然后在我的视图中再次迭代显示。我想我可以通过查看定制的保湿器来消除我的一步迭代结果步骤。
我一直在考虑建立一个实体，每个日期从系统的“起源日期”到相关的当前/未来日期，关系到周/月/季/年，这将节省我的麻烦从结果集中形成我自己的集合。这个方法看起来很不错，特别是因为当我通过日期范围来获取发票以显示在日历上时，我必须找到并传递fromDates和thruDate，这通常会延伸到前几个月和未来几个月，因为几周总计。我开始更倾向于采用这种方法，但我有一种感觉，当我开始实施它时，我将开始遇到问题。
现在这么漫游，我只会问。任何人都可以在这个主题上给我任何指示/提示/经验教训/阅读材料/等等。
感谢您的时间。
答案 0 :(得分：3)
一个想法可能是在显示数据时作为数组进行水合，并且当您需要使用单独的发票时，只需要水合成对象。
另一种方法可能是限制返回到分页列表中的实体数量，以确保返回已知的最大对象数。
希望有所帮助