0

这是一个概念问题，涉及资源的“最佳实践”和“有效利用”。专门处理数据库和在线 Web 应用程序中的大型数据集，并从过程处理方法转向更面向对象的方法。

拿一个“列表”页面，在应用程序的几乎所有 CRUD 方面都可以找到。该列表显示公司、地址和联系人。为了争论和“正确的”RDBM，假设我们已经对数据进行了规范化，使得公司可以有多个地址和联系人。- 对于我们的场景，假设我有一个包含 200 家公司的列表，每个公司都有 2-10 个地址，每个地址都有一个联系人。即“商店”被命名为“麦当劳”的任何特许经营店，但该“名称”可能有多个地址）。

表格

  • 公司
  • 地址
  • 联系人

至此，我将进行一次数据库调用并使用连接来拉回我的所有数据，循环数据并输出每一行......将在应用程序层进行一些分组以以友好的方式显示内容。（这似乎是最有效的方式，因为 RDBM 完成了繁重的工作 - 网络调用最少（一个到 db，一个来自 db，一个 http 请求，一个 http 响应）。

如果您无法在应用程序层进行分组，另一种方法是查询公司列表，循环遍历该列表，然后在循环内部为地址、联系人进行单独的数据库调用。效率较低，因为您要进行多个数据库调用

现在 - 问题或症结……从概念上讲……

如果我有一个公司对象、一个地址对象和一个联系人对象——似乎为了达到相同的结果——你会调用一个返回列表的“getCompanies”方法，然后你会遍历列表，并且为每个调用“getAdderss”，同样调用“getContact” - 传入公司 ID 等。

在 Web 应用程序中 - 这意味着从应用程序层到数据库的数据流量要多得多，以及大量较小的数据库调用等 - 似乎效率非常低。

如果您随后将相当多的此逻辑移至客户端，那么对于 AJAX 应用程序，您将在增加的内部网络开销之上产生网络流量。

有人可以评论解决此问题的最佳方法。也许它是一个概念性的东西。

有人建议当您访问这些大型数据集时使用“网关”，而不是更小的更细粒度的对象数据 - 但这并不能真正帮助我理解，我不确定它是否准确。

4

2 回答 2

0

我已经多次处理过这个问题。要记住的第一件也是最重要的事情是：不要过早优化。优化代码的可读性、DRY 原则等，然后回来修复“慢”的东西。

但是，针对这种情况，不是一次迭代地获取每个公司的地址，而是将所有公司 ID 的列表传递给 fetcher，并获取所有这些公司 ID 的所有地址，然后缓存该地址列表在地图中。当您需要通过 addressID 获取地址时，请从该本地缓存中获取它。这称为 IdentityMap。但是，就像我说的那样，我不建议在需要之前重新编码此优化的流程。大多数情况下，一个页面上有 10 个内容，而不是 100 个，因此通过更改优化流程的“正常”流程，您只需节省几毫秒。

当然，一旦你这样做了 20 次，在“优化流程”中编写代码就会变得更加自然，但你也有什么时候该做、什么时候不该做的经验。

于 2013-09-10T21:48:01.947 回答
0

当然，一次从数据库中获取所需的一切是最有效的。您不需要仅仅因为您想将代码编写为 OO 模型就放弃它。基本上，您首先从数据库中获取所有结果，然后将表格数据转换为分层形式以填充对象。“getCompanies”可以进行单个数据库调用，加入地址和联系人，并返回包含“地址”和“联系人”填充列表的“公司”对象。请参阅对象关系映射。

于 2013-09-10T17:46:19.543 回答