尋找基於文件的數據庫引擎替代 MS Access
我的公司從一開始就被束縛在這種 MS Access ‘97 .MDB 格式上。我們的模式是分層的，具有多個一對多的關係。我們正處於尋找替代方案的地步，因為 Access 的緩慢和整體笨拙開始影響我們的生產力。
我們訪問數據庫的“現代”方法涉及 DAO.Net 和大量基於雜湊的記憶體。.NET System.Collections.Generic.Dictionary 類型在這裡是天賜之物，因為沒有它，我不知道我們將如何及時完成工作。我們有多個項目，每個項目都有一個與之關聯的數據庫文件（有時是多個），我們傾向於通過以下兩種方式之一進行互動：要麼手動創建數據庫（使用我們的內部編輯器），要麼使用程序生成它以其他格式獲取我們從另一家公司收到的數據，並將其轉換為我們的格式。
在這兩種情況下，我們的通用 .NET 庫通過 Dictionary 將整個數據庫載入到雜湊表中，並通過在雜湊表中按 ID 查找值來解析對象與程式碼的關係。在自動生成數據庫時，我們使用另一組雜湊表來確定一個對像在添加之前是否已經存在於記憶體中。一旦我們完成了源數據的解析，我們就開始一個多執行緒的批量插入操作。我們這樣做是因為任何其他訪問數據庫的方法都非常慢。
我希望我已經為我的問題提供了足夠的背景資訊：是否有一個數據庫引擎，其查詢速度可以與我正在使用的雜湊表相媲美？記憶體和磁碟使用無關緊要，這些數據庫僅存在於開發人員機器上，我們將它們轉換為不同的格式以與我們的軟體一起使用。我只想擺脫我的雜湊表，但我不想犧牲速度來做到這一點。
“有沒有數據庫引擎，其查詢速度可以與我使用的雜湊表相媲美？ ” - 是的，幾乎所有現代關係數據庫管理系統 (RDBMS)，因為它們經過精心建構以利用適當的數據給定數據的上下文和統計數據的結構和數據合併算法。始終使用雜湊表、字典和多個單例 ID 查找並不總是儲存、讀取和組合數據的最有效方式。
我個人的看法是 MS Access 作為一個數據庫系統很糟糕，更何況你使用的是 ‘97 版本。因此，幾乎所有現代 RDBMS 都應該是升級版。您可能只需要將範例轉換為將數據庫儲存在專用伺服器上，而不是本地儲存在客戶端機器上，因為這是現代 RDBMS 的標準做法。
有很多選項可供選擇，但我建議選擇一個主流選項，以便有大量關於如何使用它的支持和文件。由於您已經在使用他們的堆棧，Microsoft 提供 SQL Server 作為解決方案，它功能強大且設計精良，但它是一種企業軟體，因此使用起來可能需要花錢。SQL Server 的 Express Edition 是免費的，但有幾個限制，最明顯的限制是每個數據庫大小為 10 GB。其他便宜且免費的選項還包括 PostgreSQL 和 MySQL。
切換到現代 RDBMS 的另一個顯著好處可能包括改進的並發性。