SQL和平面文件……和諧嗎？

Question

我只是在想，將應用程序的實際數據存儲在平面文件中將有多快。

現在，您不能只將所有內容存儲在一個平面文件中……有時需要進行排序和搜索，並且遞歸地遍歷目錄和文件可能會很麻煩。

現在，假設您將所有可搜索的數據存儲在數據庫中，並且有一個指向數據文件的指針字段？

但是，這對於每個應用程序來說都是非常具體的-只要我所有可搜索的數據都存儲在數據庫中，為什么我應該將實際數據存儲在數據庫中？

（鎖定，不考慮數據完整性）它會更快，但是我相信……但是，這樣做值得嗎？

Answer 1

好吧，您通常想在查詢中做一些事情，而不是搜索數據。 例如，您可能不會在名為cost_center的字段上進行搜索，但是您可能會有一個案例陳述，該陳述根據該字段中的信息進行不同的處理。 或者，您可能需要將信息串聯在一起。 您可以根據另一個字段中的信息來更新一個字段。 您今天可能不在某個字段中搜索，明天需要搜索它。

正確設計的關系數據庫可以輕松處理terrabytes的數據。

坦率地說，您甚至不應該考慮“不考慮數據完整性”。 如果您沒有數據完整性，那么您就沒有數據。

至於您想要的是一個好主意，這取決於您要存儲的數據類型以及您打算使用它進行的操作的類型。 沒有足夠的信息可以肯定地說。

Answer 2

那么“鎖定，不考慮數據完整性”應該意味着系統速度更快。 如果放棄約束，則應提高性能。

但實際上，我認為它不會更快。 RDBMS背后有很多開發時間，這就是為什么它們很快。 當然，在高度並行的情況和利用其質量的情況下，非關系數據庫的性能要優於它們。 但是，您的想法並未提供諸如利用並行性的改進……任何性能優勢都將來自於降低RDBMS的質量……

Answer 3

以及其他答案...

• 數據共享：多個客戶端如何共享訪問數據？
• 備份/還原：同步文本和“可搜索”
• 文本數據的安全性/權限
• 改變異常

Answer 4

無需僅為執行搜索而實現SQL數據庫。 許多應用程序將其數據存儲為XML，並且您可以通過多種方式進行搜索，例如使用Lucene。 它到底有多快完全取決於數據量和結構（就像數據庫一樣）。

它可以執行得非常快，但是當您要運行多個應用程序服務器時，可能會使事情復雜化。

Answer 5

BTrieve對您的描述至關重要。 在DOS時代，它是一個非常快速的數據庫。