数据架构和数据缓存；在内存数据库中是一个坏主意？答案

【问题标题】：Data Architecture and Data Caching; In Memory Database a Bad Idea?数据架构和数据缓存；在内存数据库中是一个坏主意？
【发布时间】：2014-05-09 15:00:14
【问题描述】：

我正在编写一个 .NET 应用程序，工程师将使用它来绘制和报告我们的报废和返工数据库。该应用程序将在仪表板类型的实现中提供有关应用程序启动的预置图表和报告。然后，用户将能够创建自己的图表和报告（多个图表/报告将同时打开）。应用程序需要网络连接和登录才能运行。

我的问题是关于收集和使用数据的应用程序。目前，所讨论的报废和返工数据库表大约有 100,000 行，并且以每月约 16,000 行的速度增长。

我正在寻找最佳实践或基于经验的答案，但以下是我们的一些想法：

在应用程序启动时在“mecha-query”中查询整个表，立即转换为对象以供程序的其余部分使用。将来如果表变得太大，请设置部分或全部加载。（我最喜欢，但看起来很糟糕。）
在应用程序启动时使用 SQLite 之类的东西将表的本地副本写入用户计算机，根据需要从磁盘上的 SQLite DB 查询数据，在应用程序关闭或应用程序启动时清理本地 DB如果检测到。
使用内存中的 SQLite DB，根据需要在其中查询数据。
根据需要查询 SQL Server。

对于选项 1 和 3，我担心未来 5-6 年的应用程序内存占用。使用前面描述的仪表板功能，选项 2 和 4 的优势似乎被否定了，因为无论如何应用程序基本上都需要启动时的所有数据。我也在考虑应用程序的可扩展性；也许有一天它会被移植到网络应用程序中。

谢谢！

【问题讨论】：

您描述缓存数据库，这是一个非常糟糕的主意。
对我来说听起来像是过早的优化。如果您的应用在启动时需要所有数据，那么对我来说这听起来不像是可扩展的设计。
我同意@Blam 的观点，即#4 应该是您的默认选择。但你真的想做一些性能测试，看看它是否有效/无效。如果效果不佳，请查看其他选项。缺少的一个选项是拥有一个额外的只读存储。这可能是您当前数据库的复制版本、数据仓库或某种其他类型的非规范化数据存储。不过，在您的 4 个选择中，只有第 4 个听起来像是一个远程可行的选择。
正如其他人所说，我看不出为什么只查询数据库不起作用，特别是如果表没有被更新。任何现代 RDBMS 都会做自己的数据缓存，所以加上适当的索引，我无法想象多年来的性能问题。
也许是个愚蠢的问题——鉴于您的简单用例，您是否考虑过简单地使用与 SQL 数据源绑定的 Excel？如果没有必要，不要重新发明轮子。 :)

【解决方案1】：

是的，我推荐 4

并重新考虑为什么需要在开始时构建所有对象
即使您确实需要在开始时全部构建它们，然后将它们放入字典中并让 SQL 执行 SQL 所做的操作
使用 .NET，您对集合有大小限制

我认为没有理由担心 SQL 的负载，但您也可以对字典使用 LINQ。

100,000 行甚至不接近大
1亿行，你开始变大了

【讨论】：

感谢您的详细说明。如果数据是只读且非规范化的，我很好奇选项 1-3 的缺点？缩放似乎是一个明显的问题，但似乎也可以通过简单的设置轻松修复，例如不要加载超过 3 个月前的数据。我想在开始时构建对象的原因是它在用户尝试登录时发生。然后数据也用于填充选项列表等；例如，如果您不知道哪些站点有数据，您就不知道可以选择从哪些站点获取数据。
然后做1-3。没有一个人说这是个好主意，但您似乎很想这样做。通过简单的设置修复比例。
我只是在努力学习；寻找推理或思路。我意识到4会起作用。我不担心。我担心的是为什么 1-3 除了可扩展性之外还不好。如果你能告诉我，或者如果你告诉我可扩展性是他们不好的唯一原因。我会接受这个答案。
SO 是针对特定的编程问题而不是为了学习。你有答案。不仅 1-3 有缺陷，而且您的方法也受到过早优化的影响。如果规模不足以让您解雇他们，那么我无法帮助您。
用对数据库的查询填充选项列表:)。缓存这些（并在启动时或按需刷新它们）将为用户提供即时选择。