我們希望開發一個應用程序，以便在我們的應用程序中支持不同實體（如用戶，項目，文件夾，文檔等）的自定義屬性。自定義屬性 - 無SQL數據存儲
我用google搜索了一下，看起來沒有SQL數據庫可以滿足我們的要求。你有沒有看到任何限制？什麼是使用No-SQL而不是RDBMS的prons/cons？
有很多NO-SQL數據庫可用 - http://nosql-database.org/？但是我們沒有任何使用No SQL數據庫的經驗。沒有找到比較這些NO-SQL數據庫的好文章。任何建議，我們可以使用無SQL數據存儲來實現自定義屬性功能？
有兩種方法可以解決您的問題：一個列數據庫，如Cassandra;或關係中的名稱 - 值對（也稱爲屬性值對）。
首先，Cassandra是一個結構化的鍵值存儲。一個鍵可以包含多個和可變的屬性和值。值或列分組爲列族。創建Cassandra數據庫時，列族已修復。一個家族類似於邏輯數據模型中的實體或關係中的表。列可以隨時添加到家庭中。因此，列家族的不同實例可以有不同的列，這就是你需要的。此外，列被分配給指定的鍵，因此不同的鍵在任何給定的家族中可以具有不同的列數。
可以在邏輯數據建模和關係中創建名稱值對，也稱爲屬性值對。這可以通過三個相關的實體或表來完成：
「類型」實體只是一個由類型代碼標識的代碼表，其中包含描述和其他域特徵。域指數據類型，長度，含義和度量單位。它描述了脫離上下文的屬性（即未分配）。一個例子可能是淨值金額（8位數字，小數點後兩位），右對齊，其描述是「代表客戶的總體財務價值的數值，包括液體和非液體數量」。
「價值」實體是由客戶ID和屬性類型代碼標識的關聯實體或表，並具有一個值屬性，用於爲客戶分配淨值金額類型併爲其提供值，例如「$ 2,000,000。」
但是，在關係名稱 - 值對中，在SQL中查詢有點困難，並且通常性能不佳。這可以通過將「類型」和「價值」實體非規範化爲一個來解決。而不是有三個表，你有兩個 - 一對多。實際上，Cassandra基本上是這麼做的。一個列族是一個完全展平的屬性 - 值對。
我希望這會有所幫助。如果你打算使用NOSQL，我會使用類似Cassandra的東西。如果你使用關係型，我會反規範化（即合併成一個）類型和值。關係的優點是你已經擁有了它。卡桑德拉的缺點是你必須學習它，但它是按照你想要的來構建的。
Couchbase對你來說是一個很好的答案，如果你可以把你的模型封裝到JSON中，那麼你已經在一半了。你可以有任意數量的屬性爲對象：
產品:: 001 { 「名」： 「硬盤驅動器」， 「品牌」： 「東芝」， ... ... }
學習一些簡單的模式正在從RDBMS到Couchbase，檢查他們的網絡研討會在http://www.couchbase.com/webinars或一些簡單的設計模式，在http://CouchbaseModels.com（例子是紅寶石雖然）
Couchbase的真正優勢是架構的靈活性，橫向擴展在商品硬件和速度上。在學習基礎知識之後，它更適合於敏捷過程，幾乎不需要遷移。在企業組織中，它非常有效，因爲每個列修改都需要業務流程和DBA審批。 Couchbase架構的靈活性繞過了很多這些問題。
No-sql數據庫的一大優點就是它的自由風格：在插入真實數據之前，您永遠不會指定「user，project，folder」這樣的列。列可以隨時添加。
在RDBMS中，表格模式是嚴格定義的，在運行時不能修改。
另一個優點是查詢性能。如果您查詢用戶的所有記錄（例如「Michael」），這是非常有效的，因爲數據是按照由Google命名的Big Table原則存儲的。