数据库与平面文件

我工作的公司正在尝试将使用平面文件格式的产品转换为数据库格式。我们正在处理相当大的数据文件（即25GB /文件），并且它们的更新非常快。我们需要运行查询以随机方式以及以连续方式访问数据。我试图说服他们使用数据库的好处，但是我的一些同事似乎对此不太愿意。因此，我想知道你们是否可以通过某些原因或指向我们为什么要使用数据库的帖子的链接来帮助我，或者至少要弄清楚为什么平面文件更好（如果有的话）。

1. 数据库可以处理查询任务，因此您不必手动浏览文件。数据库可以处理非常复杂的查询。
2. 数据库可以处理索引任务，因此如果像id = x的get record这样的任务可以非常快
3. 数据库可以处理多进程/多线程访问。
4. 数据库可以处理来自网络的访问
5. 数据库可以监视数据完整性
6. 数据库可以轻松地更新数据（请参阅1））
7. 数据库是可靠的
8. 数据库可以处理事务和并发访问
9. 数据库+ ORM使您能够以程序员友好的方式操作数据。

这是我前段时间已经给出的答案：

它完全取决于特定于域的应用程序需求。很多时候，直接文本文件/二进制文件访问非常快速，高效，并且为您提供了操作系统文件系统的所有文件访问功能。

此外，您的编程语言很可能已经具有用于特定解析的内置模块（或易于编写）。

如果您需要许多附加内容（INSERTS？），并且顺序/很少访问很少/没有并发性，那么文件就是您的理想之选。

另一方面，当您对并发，非顺序读/写，原子性，原子权限的需求，数据在本质上是相关的等时，使用关系数据库或OO数据库会更好。

SQLite3可以完成很多工作，SQLite3非常轻巧（不到300kb），符合ACID，用C / C ++编写，并且无处不在（如果您的编程语言中尚未包含它，例如Python-，肯定有一个可用）。即使对于最大140 TB或128 tebibytes（链接到数据库大小）的数据库文件，它也可能有用。

如果您的需求更大，甚至没有讨论，请使用功能全面的RDBMS。

正如您在评论中说“系统”只是一堆脚本一样，那么您应该看看pgbash。

如果可以购买，请勿建造。

我最近听到了这句话，确实很适合作为指导。问问自己这个……在您的应用程序的文件处理部分上花费了多少时间？我怀疑花了很多时间来优化此代码以提高性能。如果您一直使用关系数据库，那么您将花费更少的时间来处理应用程序的这一部分。您将有更多时间来处理应用程序的真正“业务”方面。

他们更快；除非您将整个平面文件加载到内存中，否则数据库几乎可以在所有情况下更快地访问。

他们更安全；数据库更易于安全备份；它们具有检查文件损坏的机制，而普通文件则没有。将平面文件中的损坏迁移到备份后，就完成了，甚至可能还不知道。

它们具有更多功能；数据库可以允许许多用户同时读取/写入。

设置完成后，它们的使用就不再那么复杂了。

一直到数据库。

但是，如果仍然需要存储文件，则除了研究XML外，没有能力使用新的RDBMS（例如Oracle，SQLServer等）。

XML是一种结构文件格式，它使您能够将事物存储为文件，但可以查询文件和其中的数据。XML文件比平面文件更易于阅读，并且可以使用XSLT轻松进行转换，以提高人类可读性。如果需要，XML也是一种很好的传输数据的方式。

我强烈建议您使用数据库，但是如果您不能走这条路，那么XML是可以的。

那么非关系（NoSQL）数据库，例如Amazon的SimpleDB，Tokio Cabinet等呢？我听说Google，Facebook，LinkedIn正在使用它们来存储其庞大的数据集。

您能否告诉我们您的数据是否结构化，模式是否固定，是否需要简单的可复制性，访问时间是否重要等？

没有提到什么类型的文件。如果它们是媒体文件，请继续使用平面文件。您可能只需要一个标签数据库，并需要某种方式将“外部BLOB”与数据库中的记录相关联。但是，如果您需要全文搜索，则只能迁移到完整的数据库。

另一方面，就物理文件数量而言，您的文件系统可能会提供上限。

SQL临时查询功能对我来说足够了。通过在表上具有良好的架构和索引，这是快速有效的并且将具有良好的性能。

除非每次引导时都将文件加载到内存中，否则请使用数据库。就那么简单。

这是假设您的大学已经拥有用于处理文件查询的程序。如果不是，则使用数据库。

数据库和平面文件之间的区别如下：

• 数据库提供了更大的灵活性，而平面文件提供了更少的灵活性。

• 数据库系统提供数据一致性，而平面文件无法提供数据一致性。

• 数据库比平面文件更安全。

• 数据库支持DML和DDL，而平面文件不支持这些。

• 数据库中较少的数据冗余，而平面文件中的更多数据冗余。