我想存儲類似於jsfiddle商店代碼的代碼。我目前使用Postgres作爲我的主數據庫，但我想知道是否更適合使用NoSQL數據庫？什麼nosql數據庫是理想用於存儲代碼/片段？
現在的代碼片段只有一個作者，但將來可能會有多個作者，我也希望恢復的能力。
我知道有關鍵/價值數據庫和麪向文檔的數據庫。哪個特定的noSQL數據庫可以滿足我的需求？還是應該堅持使用我的Postgres數據庫？
FYI：
您不能選擇非關係數據策略，而無需定義您想要對數據執行的操作。
關係數據庫設計來自規範化規則，您可以在知道自己的數據後應用這些規則。但非關係數據庫設計依賴於您的查詢而不是您的數據。
但是，如果不知道你的應用程序，我的第一個建議是堅持使用PostgreSQL。將代碼片段存儲在文本blob中，並將代碼的元數據（作者身份，日期，語言，項目等）存儲在文本blob旁邊的其他列中。你也可以考慮使用GIST索引來實現靈活的搜索。
您也可以考慮Apache Solr，它在技術上類似於面向文檔的DBMS，儘管它通常以全文搜索引擎的形式提供。
至於NoSQL數據庫，唯一的我熟悉XML（不能很好地擴展並且具有不好的併發性）和本地數據庫（如Paradox，dBase，FoxProx和Access）。我不會推薦任何這些。
我認爲它是一個NoSQL數據庫的想法應該是您的決定中較小的因素。請考慮這些事情。
冗餘。你可以同時在兩臺服務器上運行它還是支持故障切換？ （SQL Server，Interbase，Firebird）
併發性。你會在網絡上託管這個應用程序嗎？它將如何處理10個併發操作？ （PostGres，MySql，Interbase，Firebird）
速度。查找或帖子可以接受多長時間？
可嵌入性。這是一個桌面應用程序嗎？嵌入式數據庫可以讓事情更輕鬆。 （本地數據庫如Paradox，dBase，FoxPro，Access，Interbase，Firebird或SQLite）
可移植性。桌面應用程序可以在Mac，Linux，Windows上運行。 （SQLite）
聽起來像一個相對不復雜的應用程序，可以在傳統的關係數據庫或NoSQL中實現，沒有太多問題。
但是，如果您要在PostgreSQL中保留用戶基本信息，那麼將其作爲單一存儲方法堅持下去似乎是最簡單的。使用SQL數據庫和，NoSQL增加了複雜性，使數據集之間的連接更加困難（例如，您無法進行查詢以執行「列出用戶及其最近文檔」這樣的查詢），並且使其無法完成以確保兩個數據集之間的一致性。
你得到了什麼麻煩？你想要版本控制。 CouchDB將爲您提供版本控制，但是您是否應該將其用於UI級別的版本控制（例如，因爲壓縮數據庫將丟失舊版本），這是值得懷疑的。
你說得對 - 我應該堅持使用PostgreSQL，除非我有需要保證NoSQL數據庫。當事情變得更加複雜時，我將能夠提供一些真實的信息來獲得關於縮放和重構的建議。 – 2010-09-29 23:57:17
對於如何在postgres中實現版本控制，我有點無知，但我從來沒有做過。我將不得不製作一個*所有*代碼片段的表格和一個表格，其中包含「發佈」或「粘貼」號碼的主鍵，其中包含元數據幷包含「活動」或最新代碼段的外鍵，對？編輯：我正在提出這個新問題。 – 2010-09-30 00:05:44