關係數據庫以不相關的方式

以noSQL方式使用關係數據庫的優缺點是什麼？關係數據庫以不相關的方式

說noSQL我的意思是鍵值存儲與一些相當簡單的查詢語言和水平縮放。

現在我進行一個簡單的實驗，其中postgreSQL數據庫以鍵值方式設計和查詢。這裏是例子。讓它成爲User和Article，在關係模型中是一對多的。

關係：

User    Article 
| id | login | | id | user_id | title | 
|----+-------| |----+---------+-------| 
| 1 | Alex | | 1 | 1 | FooBar| 
| 2 | Ann | | 2 | 1 | GoGoGo| 
-------------- ------------------------ 
and some constraints on user id

獲取所有用戶的文章中，我們需要某種加盟。

鍵值風格：

User       Article 
| id | login | articles | | id | user_id | title | 
|----|-------|----------| |----+---------+-------| 
| 1 | Alex | 1, 2 | | 1 | 1 | FooBar| 
| 2 | Ann |   | | 2 | 1 | GoGoGo| 
------------------------- ------------------------

讓User.articles是陣列，例如和PostgreSQL有一些工具來使用數組。

在這種情況下，我將首先進行用戶的查詢，然後在獲取文章ID時將它們全部選中。我認爲這與MongdDB的收藏方式非常相似。此外，我知道，第二種情況是我的大學教師從未說過要做的事情，但看起來像這種方法非常非常具有可擴展性。

它看起來像是重塑車輪，但主要目標是爲現在使用postgres的一些有前途的項目提供可擴展的解決方案。

來源

2012-12-02 Alex Povar

存儲逗號分隔值是**不是**可擴展的。而且，當你在文章表中存儲user_id時。該信息在用戶表中是多餘的。 –

以這種方式存儲數據，因爲我認爲分片非常簡單。例如，如果通過某些服務器分發文章表，我只需要對用戶表執行一次查詢以獲取其所有文章。沒有加入。 –

您討論1：n關係的模型。但是，「用戶」和「文章」之間的關係通常是一種n/m關係？ –

我會去與n：m關係的歸一化模型。如果在創建合適的索引,SELECT後性能仍然不夠好，我可能會創建物化視圖，這些視圖會被觸發器自動更新。

在這種物化視圖中，所有相關的ID都可以聚合到一個數組中 - 或者你實際需要的任何東西。不過，我寧願不使用它作爲主數據模型。

來源

2012-12-02 16:15:29

關係數據庫以不相關的方式

回答

相關問題