用戶創建的數據庫結構：非關系數據庫還是關系數據庫？

Question

我想在數據庫記錄中包含動態字段。

例如：我想構建一個應用程序，供用戶創建自己的表單。

用戶可以創建以下表單：

個人資料：

• 全名
• 街
• 工作
• 電話
  • 家
  • 工作
  • 移動
• 興趣愛好
  • 利息1
  • 興趣2
  • 興趣3

工作：

• 名字
• 姓
• 工作
  • 部
    • 專業1
    • 專業2
  • 部
    • 專業1
    • 專業2

國家：

• 美國
  • 狀態
    • 紐約
      • 城市
        • 紐約
        • oo
    • 阿拉巴馬州
      • 城市
        • 酒吧
        • 巴茲

如您所見，這是一個非常動態的結構：

• 沒有預定義的字段數
• 沒有預定義的字段名稱
• 用戶創建數據庫的結構

所以我想知道，最好的數據庫是什么：關系型（mysql / postgresql）或非關系型（如mongodb / couchdb / cassandra）甚至是xml數據庫（如xindice）？

即使我為此選擇了非關系型數據庫，將諸如客戶和賬單信息之類的安全關鍵信息存儲在其上是否明智？

我聽說有人說，如果您的信息需要唯一性，請使用關系數據庫。 “我們不想冒兩次向客戶收費的風險”。 非關系數據庫實際上意味着什么問題？ 您不能在非關系數據庫中存儲唯一數據嗎？

我正在考慮的另一件事：是否將數據保存在非關系數據庫中意味着我將有重復的條目？

考慮以下示例：

分類：

• 辦公室

  • 應用領域
    • 文字伴侶
      • 作者：Foobar
      • 價錢：120
    • oo
      • 作者：Foobar
      • 價錢：120

• 辦公室

  • 應用領域
    • 文字伴侶
      • 作者：Foobar
      • 價錢：120
    • 酒吧
      • 作者：Foobar
      • 價錢：120

如您所見，存在相同條目的情況。 非關系數據庫如何處理這些？ 我是如此習慣於關系數據庫。

我總結一下我的問題：

• 用戶創建的數據庫結構是哪種類型的數據庫？
• 用於存儲安全性關鍵信息的非傳統數據庫嗎？
• 非真實數據庫如何處理重復項？

Answer 1

我強烈建議您為此查看CouchDB 。

1. 您使用簡單的REST API與CouchDB通信。 換句話說，它是“ 由 Web構成”，而不是像MongoDB等其他后端數據庫。 由於具有內置的Web服務器，因此CouchDB實際上可以提供表單並接收提交。
2. 作為JSON文檔存儲，它非常適合存儲尚未結構化的數據。 （表格及其提交的內容實際上是文檔，以這種方式對它們進行建模更有意義，IMO。）
3. 您可以輕松地將描述每個Web表單的JSON文檔存儲在與表單提交相同的“存儲桶”中。 （CouchDB甚至可以解析表單POST，然后將其轉換為JSON文檔，但您認為合適。例如，讓它自動為表單提交添加時間戳很簡單。）
4. 您可以編寫所謂的“ _show”函數在CouchDB中實際生成每個表單的html代碼。 還要檢查“ _update”和驗證功能。
5. 它具有您需要的安全功能。
6. 可以輕松識別文檔沖突。 更好的是，CouchDB會自動確定文檔的“勝出”版本，但您仍可以訪問“丟失”的文檔版本（直到您告訴CouchDB壓縮數據庫，從而刪除了舊修訂版。）
   • 關於唯一性：您不希望CouchDB生成唯一的doc _id，而是要分配一個_id來真正代表唯一的表單提交。 如果每個用戶只允許每個表單提交一次，則對從表單提交創建的每個JSON文檔使用以下內容submission:user:5:form:a3df2a712

使用CouchDB，您可以避免為用戶可能創建的每種表單動態創建唯一表的麻煩。

Answer 2

如果您的數據非常適合關系模型，但是您需要存儲一些動態格式化的數據，這些數據不是很大，那么最好將JSON，XML或類似的數據存儲到列中。 盡管這樣做會使您失去一流SQL輸入的某些優勢（索引編制，外鍵約束檢查，類型檢查等），但是當您的查詢不太在意它們的內部時，它對於存儲動態結構化文檔非常有用。

如果您有興趣通過JSON / XML / etc等來存儲大部分關系數據，建議您使用PostgreSQL。 PostgreSQL有XML數據類型，但是我不推薦使用它，因為我討厭XML：P。 沒有人阻止您將JSON存儲在TEXT字段中，但是PostgreSQL很快將具有支持功能的JSON數據類型。 hstore contrib模塊提供了一種存儲鍵/值對的有效方法，並且還提供了全文本索引支持。

盡管將JSON或類似的東西推到SQL數據庫列中雖然是關系模型的事，但是您通常還是最好這么做（在有意義的時候！）。 否則，您必須向數據庫解釋應用程序的整個架構，從而導致很多SQL和數據庫映射代碼實際上什么也沒做。

Answer 3

選擇的數據庫更多地取決於您要查詢的內容和方式，而不是要存儲的內容。 所有的數據庫將使您幾乎存儲任何您想要的東西。

RDBMS特別擅長基於關系模型的查詢，並且可以合理地任意進行。 通過臨時過濾器和聯接，您可以進行各種魔術。

NOSQL DB的查詢靈活性較差，但在其他任務上卻做得很好（例如，對“非結構化”數據的處理更好）。

鑒於您在此處發布的內容，我將只使用一個SQL數據庫並按照用戶想要的定義表。 設置索引，設置查詢。 聽起來對我來說真是不費吹灰之力。 SQL DB可以輕松處理所有這些“動態定義字段”的內容，因為...這就是它們的工作。 所以用那個。