我只是在想，將應用程序的實際數據存儲在一個平面文件中有多快。SQL和平面文件...和諧嗎？
現在，你不能只將所有內容存儲在一個平面文件中......有時需要進行排序和搜索，並且遞歸地瀏覽目錄和文件可能是一個痛苦。
現在，想象一下，您將所有可搜索的數據存儲在數據庫中，並且有一個指向數據文件的指針字段？
然而，這將是非常具體的每個應用程序，只要我的所有可搜索的數據存儲在數據庫中，爲什麼我應該將實際數據存儲在數據庫中？ （鎖定，數據完整性放在一邊）它會更快，我相信...但是多少，值得這樣做嗎？
沒有必要爲了執行搜索而實現SQL數據庫。許多應用程序以XML格式存儲數據，並且可以通過多種方式進行搜索，例如使用Lucene。它的速度完全取決於數據量和數據結構 - 就像數據庫一樣。
它可以執行得非常快，但是當您想運行多個應用程序服務器時可能會使事情變得複雜。
BTrieve是你描述的基本要素。回到DOS時代，這是一個非常快速的數據庫。
那麼你經常想在查詢之外做的事情超出搜索數據。例如，您可能不會在名爲cost_center的字段上進行搜索，但您可能有一個案例統計信息，根據字段中的信息對事物進行不同的處理。或者您可能需要將信息連接在一起。您可能會根據另一個字段中的信息更新一個字段。你今天可能不在現場搜索，需要明天搜索。
正確設計的關係數據庫可以很容易地使用terrabytes的數據執行。
坦率地說，你甚至不應該考慮「數據完整性」。如果你沒有數據完整性，你就沒有數據。
至於你想要的是不是一個好主意，它取決於你正在存儲的數據的類型以及你打算使用的類型。沒有足夠的信息可以肯定地說。
那麼「鎖定，數據完整性放在一邊」應該意味着更快的系統。如果你放棄限制，你應該提高性能。
但實際上，我認爲這樣做會更快。 RDBMS背後有很多開發時間，這就是爲什麼它們很快。例如，非關係數據庫在高度並行的情況下可以比他們的表現更好。然而，你的想法不提供改進，如利用並行......任何性能上的優勢將來自跌落的RDBMS的素質......
以及其他答案...