n层系统是否对大数据集处理有“意义”？

Question

我最近成为编写我们的“旗舰”产品的开发团队的一员。它主要是一个阅读密集型Web应用程序（asp.net（c＃）和oracle），在N层系统中实现。大部分数据库中的写入都是通过外部服务完成的（不是通过webapp）。与其在数据库中安排正常的批处理作业以进行数据聚合，不如将业务层中的所有内容（有时创建一亿个对象）推到一起。虽然这确实使所有“业务逻辑”保持在同一地点，但它也比在数据库中运行等效查询的时间长大约200倍。这对我来说似乎是一个可怕的想法。我错在这里，这是标准和好东西？有人有任何真实的案例研究，我可以指出我的同事（或者如果我错了）我的同事？

我不是在辩论n层是好还是坏，但它是否适合数据聚合处理等？

Answer 1

你是正确的处理时间（和资源，如内存）。

• 最佳做法是将最接近可能的数据聚合在一起，最好是在数据库中。一亿个物体看起来很疯狂。
• 但是，我们都知道这种代码不易维护。所以这是更多的开发时间，并且最终成本更高。

所以你需要达到一个正确的平衡。这不能从外面来，
你必须仔细权衡在您的项目的具体情况下的优势。

例如，频率这一切发生很重要。成本高，显然是可以接受的，如果过程发生的每一分钟，但如果它每年发生的可能不是...

---

也许正确的平衡将采取两者兼而有之。例如，对于良好的投资回报率：

• 对数据库的查询可以执行第一级聚合，摆脱微小的细节，并将要创建的对象的数量减少一百。
• 业务层可以适用的其他规则

是什么让一个很好的候选人的要求被照顾查询：

• 那滴（的对象的数量水平低聚合或者说摆脱数据库的线）
• 规则很少变动
• 规则，在SQL

轻松阅读

为了让您的代码更加明确（并减少查询之间的重复），我建议您的代码采用编译时结构来清除它。创建显式常量或函数，以体现将放入查询中的每个业务规则，并使用该常量或函数构建（在运行时或编译时）查询。