我只是在想，将应用程序的实际数据存储在平面文件中会有多快。
现在，您不能只将所有内容存储在一个平面文件中...有时需要进行排序和搜索，并且递归地浏览目录和文件可能会很痛苦。
现在，想象一下，您将所有可搜索的数据存储在数据库中，并有一个指向数据文件的指针字段？
这对于每个应用程序来说都是非常具体的，但是，只要我所有可搜索的数据都存储在数据库中，我为什么要将实际数据存储在数据库中？
（锁定，数据完整性除外）它会更快，我敢肯定...但是多少，值得这样做吗？
【问题讨论】：
嗯，您经常希望在查询中做一些事情，而不是搜索数据。例如，您可能不会在名为 cost_center 的字段上进行搜索，但您可能有一个案例陈述，它根据字段中的信息以不同方式处理事情。或者您可能需要将信息连接在一起。您可以根据另一字段中的信息更新一个字段。您今天可能不会搜索某个字段，而明天需要对其进行搜索。
设计合理的关系数据库可以轻松地处理 TB 级数据。
坦率地说，您甚至不应该考虑“撇开数据完整性”。如果你没有数据完整性，你就没有数据。
至于你想要的是否是一个好主意，这取决于你存储的数据类型以及你打算用它做的事情的类型。没有足够的信息可以肯定地说。
【讨论】：
好吧，“锁定，数据完整性除外”应该意味着更快的系统。如果你放弃约束，你应该提高性能。
但实际上，我认为它不会更快。 RDBMS 背后有很多开发时间，这就是它们速度快的原因。当然，例如，非关系型数据库在高度并行的情况和利用其特性的场景中表现得比它们更好。但是，您的想法并没有提供诸如利用并行性之类的改进……任何性能优势都来自于降低 RDBMS 的质量……
【讨论】：
还有其他答案...
【讨论】：
没有必要仅仅为了执行搜索而实现 SQL 数据库。许多应用程序将其数据存储在 XML 中，您可以通过多种方式进行搜索，例如使用 Lucene。它的速度完全取决于数据量以及您如何构建它 - 就像数据库一样。
它的执行速度非常快，但是当您想要运行多个应用服务器时，它会使事情变得复杂。
【讨论】：
BTrieve 是您所描述的重要内容。在 DOS 时代，它是一个非常快的数据库。
【讨论】：