平面文件与RDBMS数据库，很少读/写，很少更改

Question

我必须处理来自长期(数年，几十年)气候监测站的数据。数据流通常从原始数据(电压等)开始。加上质量检查信息(压力、温度、流量等)一般记录为@ 1Hz。然后，给数据分配一个质量标志(人和/或程序)，处理(应用校准曲线)并标记。

因此，我们基本上得到了两个数据集:原始数据和处理数据。新数据通常每天添加一次(~500 day /日/仪器)。同时查询不太可能发生。

我想选择一个关系型数据库管理系统(我们有一个MySQL服务器)，并且在数据库设计方面有一些经验，但是IT人员一直告诉我，平面文件也同样适用于这项工作。当涉及到备份/升级MySQL时，我怀疑他试图使他的生活变得更容易。

数据之间的链接不多，变化不大，但是质量标志会发生变化。相对于每天的文本文件，RDBMS更容易在“多天”的范围内比较来自不同仪器的数据。

那你有什么建议？

谢谢。

Answer 1

在我自己的办公室里，我正面临着一场非常相似的辩论:我们有一个大型的遗留系统，它使用平面文件，并试图说服一些长期用户切换到数据库。这不是一个简单的决定，有很多，很多问题，你需要仔细考虑。这里有几个：

迁移到DB：

的好处：

当然，有一些是数据库系统的许多优点，但我认为在您的情况下最相关的是：

• 挠性分析也许数据库存在的理由--它们能够进行复杂、复杂、面向关系的搜索和查询。与Excel相比，您真的可以用更复杂的方式对数据进行切片和骰子。
• 可伸缩性。一旦您进入了千兆字节的数据领域，文本文件实际上就开始扩展到接缝处。在这种规模下，数据库可以更高效、更有弹性。
• 可用性和一致性。如果有多个用户在同一数据上进行协作，数据库可以确保每个人都在查看同一个版本，并且可以帮助防止人们覆盖对方的标志。

缺点：

当然，尽管DBs很有用，但在您的情况下，有许多因素可能会排除它们：

• 破坏。有多少用户将使用这个新系统？它们在当前系统中的投资有多大(有多少Excel宏、脚本文件和工作流必须放弃或重新配置？)还有多少其他应用程序需要与数据交互？
• 学习曲线对于那些不熟悉DBMS的人来说，DBMS可能是一个真正的瓶颈。谁来训练使用者？他们钟爱的数据现在会被“锁”在某个DBA的办公桌后面吗？他们将不得不学习读写SQL，以及如何与MySQL接口交互，除非您计划为他们创建一个复杂的前端应用程序(这是一项艰巨的任务！)
• 技术支持。谁来管理dbms软件和服务器(升级、补丁、中断等)？你已经表示过它不愿意。你准备好自己处理了吗？
• 成本。尽管MySQL是免费的，但还有其他的转换成本需要考虑，特别是迁移时间。管理层是否准备好在生产时间上填补几个月的空白？

最后，您需要自己来衡量工作流的中断是否值得您感知到的优势。在我看来，我建议，除非和直到其他系统的用户对现状非常不满，你真的需要仔细考虑你是否想在这场战斗中花费你的芯片。

Answer 2

这些文件的存储要求允许您同时使用吗？将平面文件导入数据库以进行数据分析，但要维护一个可以备份的平面文件的归档文件。最终，我认为RDBMS解决方案对他们来说会更加灵活，并允许他们收集统计数据，否则从平面文件中派生出来会更加繁琐。他们可能很快就会发现，是的，现在他们有能力以更灵活的方式查询数据，实际上他们对这些数据很感兴趣。

Answer 3

根据我对你描述的理解：

1. 数据中没有唯一的键。
2. 所有的更改都是按顺序顺序发生的，它们一次影响一个文件。
3. 记录/行之间没有任何关系。
4. 不需要随机查询或随机插入/更新
5. 对谁可以访问数据没有安全风险。
6. 这些数据不被在线系统使用，也不被多个系统共享。

从上述情况来看，这是批处理文件处理的典型情况。如果从第2点到第6点中的任何一点是假的，请使用db。

为了使您的生活更容易，您可以做的一件事是正确地构造您的文件名和目录，以便您可以在将来自动地将文件集加载到数据库中。良好的命名转换将有很大帮助。