.net - 不使用数据库但在内存对象中使用是不是很糟糕？

Question

我的任务是编写一个供单个用户使用的小应用程序。这个应用程序将从我们的主员工数据库中提取约 500 个员工姓名/部门。然后用户将为每个员工输入 5 个字段。这 5 个字段通常每年只更改一次，但最坏的情况可能是每月一次。我只应该在任何给定时间跟踪 2 年的值(value)。

我看过 SQLite 和 SQL CE，但我对它们中的任何一个都不感兴趣。 SQL CE 不想让数据文件驻留在网络共享上。 (只有一个用户，但他们将所有文档存储在每天备份的私有(private)共享中)。

SQLite 似乎更符合要求，但如果没有包装器或任何东西，它就不能很好地集成到 Visual Studio 中。

另一件要考虑的事情是，我们的员工精通 MS 的 SQL Server 和其他东西，所以拥有他们理解的东西 vs SQLlite 对我的老板来说将是一件重要的事情。

所以我的问题是:如果我将数据存储在内存中的对象中并在保存时将它们序列化到磁盘会怎样。我做了一个快速测试，有 10k 人(我们最多只能使用 500-1000)，每个人 10 年(如果他们每月更新数据，则为 10 个月，极不可能)只导致我的演示应用程序使用 30MB内存。即使使用 GUID 随机填充所有字符串，也可以即时填充数据。这是一个坏主意吗？它是一个相当简单的应用程序，在这种情况下，对我来说似乎没问题。

Answer 1

我发现使用对象序列化持久化业务数据的想法存在一些问题:

这些不一定是这个想法的阻碍，而是需要考虑的事情......

数据无法查询、上报、检查。它完全被应用程序不透明地捕获。

调试序列化数据比能够查看数据库中的相应数据，甚至是像 CSV 这样的格式更难。

没有原子性 - 一次电源故障或应用程序崩溃可能会破坏整个“数据库”。

如果数据模型发生变化，更新现有的持久化实体需要一个可以读取新旧格式的应用程序版本。使用数据库，您只需添加一列(或子表)。

没有干净的方法来实现并发访问。如果多个用户想要查看或编辑数据会怎样？

我学到的一件事是，小型应用程序往往会增长并成为“大型应用程序”。 当组织错误地猜测应用程序的潜在值(value)时，他们往往会在以后承担这种意想不到的有机增长的成本。

您还提到您喜欢 SQLLite 并且不喜欢它。你不喜欢什么？你预计会出现什么样的问题？

如果你只是在寻找一种“偷工减料”的方法来更快地完成这项工作——这在短期内可能没问题——但要小心——这些决定会反过来咬你。