我應該使用哪個數據庫來存儲記錄，我應該如何使用它？

Question

我正在開發一個存儲大量記錄的應用程序。 這些記錄將類似於（URL，日期，標題，來源，{可選數據...}）

由於這是一個客戶端應用程序，我不想使用數據庫服務器，我只想將信息存儲到文件中。

我希望這些文件可以從各種語言中讀取（至少是python和C ++），所以像python的pickle這樣的語言特有的東西不在游戲中。

我看到兩種可能性：sqlite和BerkeleyDB。 由於我的用例顯然不是關系型的，我很想和BerkeleyDB一起使用，但我真的不知道如何使用它來存儲我的記錄，因為它只存儲鍵/值對。

我的推理是否正確？ 如果是這樣，我應該如何使用BDB存儲我的記錄？ 你能把我鏈接到相關信息嗎？ 或者我錯過了更好的解決方案？

Answer 1

我看到兩種可能性：sqlite和BerkeleyDB。 由於我的用例顯然不是關系型的，我很想和BerkeleyDB一起使用，但我真的不知道如何使用它來存儲我的記錄，因為它只存儲鍵/值對。

你所描述的正是關系的意義所在，即使你只需要一張桌子。 SQLite可能會讓這很容易。

編輯：關系模型與表之間的關系沒有任何關系。 關系是其他集合的笛卡爾積的子集。 例如，實數，實數和實數的數據（是的，所有三個相同）產生3d坐標空間，您可以使用公式定義該空間的關系，例如x*y = z 。 每個可能的坐標集(x0,y0,z0)如果滿足給定的公式則處於關系中，否則它們不是。

關系數據庫使用此概念以及一些額外要求。 首先，最重要的是，關系的大小必須是有限的。 上面給出的產品關系不滿足該要求，因為有無限多的3元組滿足公式。 還有許多其他考慮因素與實際計算機解決實際問題的實際或有用之處有關。

思考問題的一種更好的方法是考慮每種類型的持久性機制在哪些方面比另一種更好。 當您有許多必須支持它們之間的關系（外鍵約束）的單獨數據集（表）時，您已經認識到關系解決方案是有意義的，這幾乎不可能通過鍵值存儲實施。 關系的另一個真正優勢是它可以通過使用適當的索引來實現豐富的即席查詢。 這是數據庫層實際理解它所代表的數據的結果。

鍵值商店擁有自己的一系列優勢。 其中一個更重要的是鍵值存儲擴展的方式。 memcached ， couchdb ， hadoop都使用鍵值存儲是沒有意義的，因為很容易在多個服務器上分發鍵值查找。 鍵值存儲運行良好的另一個領域是當鍵或值不透明時，例如當存儲的項目被加密時，只有它的所有者可讀。

---

要將這一點推向家庭，即使您不需要多個表，關系數據庫也能正常工作，請考慮以下內容（非原創）

SELECT t1.actor1 
FROM workswith AS t1, 
     workswith AS t2, 
     workswith AS t3, 
     workswith AS t4, 
     workswith AS t5,
     workswith AS t6
WHERE t1.actor2 = t2.actor1 AND
      t2.actor2 = t3.actor1 AND
      t3.actor2 = t4.actor1 AND
      t4.actor2 = t5.actor1 AND
      t5.actor2 = t6.actor1 AND
      t6.actor2 = "Kevin Bacon";

其中，顯然只使用一個表： workswith計算每個演員具有6:1培根數

Answer 2

BerkeleyDB很好，也看看* DBM化身（例如GDBM）。 但最大的問題是：你需要搜索什么？ 您是否需要按該網址，一系列網址或您列出的日期進行搜索？

也可以將記錄組保存為本地文件系統中的簡單文件，按日期或搜索條件分組，＆c。

回答“搜索”問題是最大的開端。

至於key / value thingy，你需要確保的是KEY本身已經很好地定義了你的查找。 例如，如果您需要按日期按日期查找，而其他按標題查找，則需要維護“記錄”行，然后可能需要2個或更多“索引”行來引用原始記錄。 您可以在鍵/值存儲中建模幾乎任何內容。

Answer 3

就個人而言，無論如何我會使用sqlite。 它一直為我（以及我合作的其他人）工作過。 當您的應用程序增長並且您突然想要做一些更復雜的事情時，您將不必重寫。

另一方面，我在Python開發人員列表中看到過關於Berkely DB的各種評論，這些評論表明它並不精彩; 你只能獲得dict風格的訪問權限（如果你想選擇某些日期范圍或標題而不是URL，該怎么辦）; 它甚至不是Python 3的標准庫集。

Answer 4

那么MongoDB呢？ 我還沒試過，但看起來很有趣。

Answer 5

如果您只想使用單個字段來查找記錄，那么簡單的鍵值存儲將是一個不錯的選擇。 將該單個字段（或任何其他唯一ID）存儲為您的密鑰，將每個記錄序列化為字符串（使用JSON或類似字符串），並將該字符串存儲為值。 Berkeley DB無疑是鍵值商店的合理選擇，但有很多選擇可供選擇： http ： //en.wikipedia.org/wiki/Dbm

如果您想通過幾個字段中的任何一個查找記錄，SQLite可能最容易用於開發目的。 您將在SQL中編寫查詢，但您不必維護數據庫服務器。 所有的多功能機器都已經為您編寫。

如果您真的想要避免SQL或從數據存儲中擠出所有性能， 並且您想要多鍵訪問，請考慮在鍵值存儲之上添加一層額外邏輯。 通過序列化記錄並將每個記錄的“列”值插入其值包含記錄的“主”鍵的附加鍵，可以在鍵值存儲之上構建類似行的行為。 （您實際上將鍵值存儲用作記錄字典和索引字典以查找這些記錄。）Google的App Engine就是這樣做的。 您可以自己執行此操作，也可以使用各種面向文檔的數據庫中的一種來為您執行此操作。 對於一些有趣的閱讀，嘗試谷歌搜索“nosql”。 http://www.google.com/search?&q=nosql

Answer 6

好的，所以你說只是存儲數據..？ 你真的只需要一個DB來檢索，查找，總結等等。因此，對於存儲，只需使用簡單的文本文件和追加行。 如果需要，壓縮數據，在字段之間使用delim - 幾乎任何語言都能讀取這些文件。 如果您確實想要檢索，那么請關注您的檢索需求，按日期，按鍵，哪些鍵等。如果您想要簡單的客戶端，那么您需要簡單的客戶端數據庫。 SQLite比BDB容易得多，但是看看像Sybase Advantage這樣的東西（非常快速且對本地客戶端而言是免費的，但不是開源的）或VistaDB或firebird ......但是所有這些都需要本地配置/設置/維護。 如果您使用本地XML獲取“相當大”的記錄數量，則會為您提供一些不必要的文件大小......！