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

Question

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

我看过SQLite和SQL CE,我对其中任何一个都不感兴趣.SQL CE不希望允许数据文件驻留在网络共享上.(只有一个用户,但他们将所有文档存储在每天备份的私有共享上).

SQLite似乎更适合该法案,但它没有整合到没有包装或任何东西的Visual Studio中.

另一件需要考虑的事情是,我们的人员精通MS的SQL Server而其他方面很少,因此他们对SQLlite的理解对我的老板来说将是一件重要的事情.

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

Answer 1

我看到使用对象序列化持久化业务数据的一些问题:

这些不一定是这个想法的显示器,而是需要考虑的事情......

1. 无法查询,报告或检查数据.应用程序完全不透明地捕获它.
2. 调试序列化数据比查看数据库中的相应数据甚至像CSV这样的格式更难.
3. 没有原子性 - 一次电源故障或应用程序崩溃可能会破坏整个"数据库".
4. 如果数据模型发生更改,则更新现有的持久化实体需要一个可以读取旧格式和新格式的应用程序版本.使用数据库,您只需添加一个列(或子表).
5. 没有干净的方法来实现并发访问.如果多个用户想要查看或编辑数据,会发生什么？

我学到的一件事是,小应用程序往往会成长并成为"大型应用程序".当组织错误地猜测应用程序的潜在价值时,他们往往会产生这种意外的有机增长的成本.

你还提到你喜欢SQLLite并且不喜欢它.你不喜欢什么？你期待什么样的问题？

如果你只是想找到一种"偷工减料"的方法来更快地完成这项工作 - 这在短期内可能会好起来 - 但要小心 - 这些决定有可能回过头来咬你.