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

Question

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

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

Answer 1

你对处理时间（以及内存等资源）是正确的。

• 最佳做法是将最接近的数据聚合在一起，最好是在数据库中。一亿个对象看起来很疯狂。
• 但是，我们都知道代码的可维护性较差。因此，开发时间更长，最终成本更高。

所以你需要达到正确的平衡。这不能从外面来到你身边，
您必须仔细权衡项目特定环境中的优势。

例如，频率所有这一切都很重要。如果过程每分钟发生一次，那么高成本显然是可以接受的，但如果每年都发生这种情况可能不会......

---

也许正确的平衡会占用两者。例如，为了获得良好的投资回报率：

• 对数据库的查询可以进行第一级聚合，删除微小的细节，并将要创建的对象数量减少一百。
• 业务层可以应用其余规则

在查询中需要注意的一个好的候选人是什么：

• 低级别聚合，用于删除从数据库中出来的对象（或行）的数量
• 很少改变的规则
• 在SQL中轻松阅读的规则

  

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