c# - 数据库、请求、性能、缓存

Question

我需要一些关于如何设计数据库层的输入。

在我的应用程序中，我有一个 T 列表。T 中的信息包含来自多个数据库表的信息。

当然有多种方法可以做到这一点。我想到的两种方法是:

繁琐的数据库层和可缓存的:

List<SomeX> list = new List<SomeX>();
foreach(...) {
    list.Add(new SomeX() {
        prop1 = dataRow["someId1"],
        prop2 = GetSomeValueFromCacheOrDb(dataRow["someId2"])
    });
}

我在上面看到的问题是，如果我们想要一个包含 500 个项目的列表，它可能会发出 500 个数据库请求。随着所有的网络延迟等等。另一个问题是，在我们从数据库中获取列表之后但在我们尝试从缓存/数据库中获取列表之前，用户可能已被删除，这意味着我们将遇到空问题。我们必须手动处理。好处是它具有高度可缓存性。

非聊天但不可缓存:

List<SomeX> list = new List<SomeX>();
foreach(...) {
    list.Add(new SomeX() {
        prop1 = dataRow["someId1"],
        prop2 = dataRow["someValue"]
    });
}

我在上面看到的问题是它很难缓存，因为可能所有用户都有唯一的列表。另一个问题是会有很多连接，这可能会导致对数据库进行大量读取。好消息是我们可以确定在查询运行后所有信息都存在(内连接等)

不那么啰嗦，但仍然可以缓存

第三种选择可能是首先循环遍历数据行，收集所有必要的 someId2，然后再发出一个数据库请求以获取所有 SomeId2 值。

Answer 1

“我在上面看到的问题是，如果我们想要一个包含 500 个项目的列表，它可能会发出 500 个数据库请求。加上所有的网络延迟等等。”

没错。还可能造成不必要的争用，并在您迭代查询时消耗维护锁的服务器资源。

“另一个问题是，在我们从数据库中获取列表之后但在我们尝试从缓存/数据库中获取列表之前，用户可能已被删除，这意味着我们将遇到空值问题。”

如果我接受那句话，那么这句话:

“好处是它是高度可缓存的。”

不是真的，因为你已经缓存了过时的数据。所以打掉目前为止唯一的优势。

但要直接回答您的问题，最有效的设计(这似乎就是您要问的)是将数据库用于其有益的用途，强制执行 ACID 合规性和各种约束，最显着的是 pk 和 fk，但是还用于返回聚合答案以减少应用程序端的往返行程和浪费的周期。

这意味着您要么将 SQL 放入您的应用程序代码中，这已被代码思想警察裁定为 Infinite Bad Taste，要么转到 sprocs。两者都有效。将代码放入应用程序可使其更易于维护，但您再也不会受邀参加任何更优雅的 OOP 派对。