.Net 持久性大列表和近乎实时地保持数据最新

Question

好的，请稍等，因为这有很多层次，尽管阅读所有这些内容可能需要一些时间，但我认为我们所有人提出的答案将对整个社区非常有用。话虽如此，让我设置问题：

我有一个 C# .Net 桌面应用程序（Windows 窗体，但我认为它也可以是 WPF），它是一个销售订单输入和管理系统。我遇到的问题是我需要在应用程序中使用的最重要的数据列表之一相当大（大约 15k 条记录，并且还在增长）并且不断变化，我想保留列表内存与数据库同步，而不是每 2 秒或其他时间轮询数据库。该应用程序也不是单实例，因此应用程序需要的所有这些列表都从数据库中带入内存，并在每个实例中保存一次。

好的，既然你已经看到了困境，让我们看看我们是否能想出一个解决方案。

我的想法：

如果我们能够使用 .NET 4.0（我可以），我认为在内存中只保留一组数据的答案是使用内存映射文件。虽然从表面上看是本垒打，但管理起来要复杂得多，而且可能有点矫枉过正。想法？

为了将数据库中的数据负载保持在最低限度，我正在考虑将各种列表保存到用户 PC 上某个特殊文件夹中的 XML 文本文件中，然后使用一个最终的 XML 文件来跟踪 XML 文件和他们的日期。在应用程序启动时，执行对数据库的单个调用，获取表/列表的列表以及每个的“最后更新日期”。对于具有相同上次更新日期的每个 XML 文件，我可以从 XML 文件加载而不是查询数据库。至于过期的列表，我可以查询自拥有日期以来的更改，然后加载 XML 文件，然后提交更改。这样，我不得不等待的唯一更改很可能是来自更频繁更新的列表的更改，而不是所有表/列表。好吧，我承认我不是最擅长解释事物，但我认为您应该能够将其形象化。

至于实时保持最新状态，我正在考虑使用插入和更新触发器（不会发生删除）来调用 SP，这就是我有点模糊的地方，以某种方式传递插入的/updated 信息到应用程序订阅的 WCF 服务，并通过 WCF 回调将更新推送到客户端。现在我认为这应该一切正常，但是，例如，这不会导致应用程序的 3 个实例同时更新内存中的相同变化吗？ WCF 服务是否只能将更新发送到每台客户端 PC 的一个实例？能区分吗？

提前感谢您对此提出的任何想法、意见和意见。我将保留“奖励”一个答案至少 48 小时，因为我想让每个人都有机会投入 2 美分，让这个线程对未来更有用...

Answer 1

我看不到将数据库保存在内存中的好处。数据库的意义在于成为一个数据库。

您将不得不在您的应用程序中重现多用户数据库功能。

这似乎是一个没有胜利的提议。把它留给微软。而是制作一个使用 sql server 的所有功能的 n 层应用程序。然后，当您有一个可用的测试版时，寻找应用程序中运行缓慢并从那里移动的部分。

Answer 2

实现这一目标的一种方法，也许是最好的方法是通过日记。

要实现这一点，请将日志表与您需要在每个客户端上保持更新的数据库表相关联。该表的主键是时间戳。每当任何客户端在（例如）客户表中更新或插入一行时，它也会在日志表中添加一行，指示已添加或更新的客户的主键。

然后每个客户端都可以通过查询日志表找到更改列表，找到主键大于或等于客户端上次查询（客户端跟踪）的时间戳的所有行。对客户表的简单连接获取所有新的和更新的行。然后，客户端将这些行合并到其客户表的本地副本中。

您说您不想每 2 秒或其他任何时间访问数据库。对此的三个想法。

首先，原型应该足够简单，并确定是否每 2 秒访问一次数据库实际上是您需要解决的问题。

第二次：每 2 秒一次？在我看来，这听起来像是一种由对魔法的信念驱动的需求，而不是由实际的业务需求驱动的需求。而如果是业务需求驱动的话，我会担心更深层次的问题，比如：假设用户执行一个涉及客户的交易需要超过 2 秒，如果在交易过程中客户行发生变化会发生什么？

最后：即使您最终确实需要实现广播模型，广播的起点也将是需要发送给客户端的项目的工作队列。日记是一个很好的起点。

Protip：不要忘记实施从日记帐表中清除旧条目的日终流程。

Answer 3

我的程序有类似的需求，但我的解决方案是构建延迟加载数据库对象的类（因为它们是需要的），甚至部分用于一些更重要和更大的项目（只是主键和开头的名字）。然后，每当我正在查看的数据库项未初始化（只是 PK 和名称）或仍然为空时，我都会转到数据库并急切地加载该对象和其他几个同类对象。

如果你有一个包含 15k 项的 UI 元素，那么你的程序将几乎无法被人类使用（也可能根本不显示任何内容，只将其保存在列表中）。您应该考虑使用搜索对话框或类似的东西。