アプリケーションの実際のデータをフラットファイルに保存するのがどれだけ速いかを考えていました。
今では、すべてをフラットファイルに保存するだけでは不十分です...ソートと検索が必要になる場合があり、ディレクトリとファイルを再帰的に調べるのは面倒な場合があります。
ここで、検索可能なすべてのデータをデータベースに保存し、データファイルを指すポインターフィールドを持っていたと想像してみてください。
これはアプリごとに非常に具体的ですが、検索可能なすべてのデータがデータベースに保存されている限り、実際のデータをデータベースに保存する必要があるのはなぜですか？
（ロック、データの整合性は別として）それはより速くなるでしょう、私は確信しています...しかしどれくらい、そしてそれはそれをする価値がありますか？
まあ、「ロック、データの整合性は別として」は、より高速なシステムを意味するはずです。制約を削除すると、パフォーマンスが向上するはずです。
しかし、実際には、それが速くなるとは思いません。RDBMS の背後には多くの開発時間があり、それが RDBMS が迅速である理由です。確かに、非リレーショナル データベースは、たとえば、その特性を利用する高度に並列化された状況やシナリオでは、それらよりも優れたパフォーマンスを発揮します。ただし、あなたのアイデアは、並列処理を利用するなどの改善を提供しません...パフォーマンス上の利点は、RDBMSの品質を落とすことからもたらされます...
データの検索を超えてクエリで何かをしたいことがよくあります。たとえば、cost_center というフィールドを検索しない場合がありますが、フィールド内の情報に応じて物事を異なる方法で処理するケース ステートメントがある場合があります。または、情報を連結する必要がある場合もあります。別のフィールドの情報に基づいて、1 つのフィールドを更新する場合があります。今日はフィールドを検索せず、明日は検索する必要があるかもしれません。
適切に設計されたリレーショナル データベースは、テラバイト規模のデータを簡単に処理できます。
率直に言って、「データの整合性はさておき」と考えるべきではありません。データの完全性がなければ、データはありません。
あなたが望むものが良いアイデアであるかどうかに関しては、保存しているデータのタイプと、それを使って何をしようとしているかによって異なります。確かに言うには十分な情報がありません。
他の回答と同様に...
検索を実行するためだけにSQLデータベースを実装する必要はありません。多くのアプリケーションはデータをXMLで保存し、Luceneを使用するなど、さまざまな方法で検索できます。どのくらいの速さであるかは、データベースのように、データの量とその構造に完全に依存します。
非常に高速に実行できますが、複数のアプリサーバーを実行する場合は複雑になる可能性があります。
BTrieveは、あなたが説明するものに不可欠でした。DOS の時代には、非常に高速なデータベースでした。