如何使深層次結構非規範化？

我讀過很多關於Cassandra和非規範化和物化的藝術，同時編寫數據。我想我理解這個概念，而且這似乎是有道理的。但是，在存在深層次數據結構的情況下，我遇到了一些麻煩。如何使深層次結構非規範化？

考慮做作域，其中

業主1：*公司
公司1：*團隊
隊1：*玩家
玩家1：*設備

我們對每個這些表實體，但我們也想快速查詢設備屬性，所以似乎要做的是創建一個表（OwnerEquipment），它擁有所有者ID和設備ID作爲主鍵，並將所有者ID作爲分區鍵。這很有道理，但如果添加和編輯設備的UX場景不包含作爲工作集的一部分的所有者ID，那該怎麼辦？

我在研究中遇到的大多數非規範化示例通常都是單級父 - 子或主 - 細節類型用例。當更新孩子寫非規範化的反向索引時，更新客戶端有足夠的關於直接父母的信息似乎是非常合理的，但是如果你真正想要反規範化的數據是多個「加入」，那該怎麼辦呢？

當我們考慮將公司出售給其他所有者時，在我們的示例中進一步說明了這個問題。假設所需的行爲是爲OwnerEquipment反映這種變化。將更新的公司寫入數據庫的代碼應該如何處理OwnerEquipment表更新？是否應該知道舊所有者的ID，嘗試更新該所有者的所有OwnerEquipment記錄？這似乎是一個非Cassandra-y的事情，也充滿了併發問題。隨着鏈條的進入（團隊到新公司，玩家到新團隊），問題變得更加嚴重。在這些情況下，「老主人」不一定在工作集中，需要閱讀才能更新。

有沒有更好的方法來思考這個問題？

來源

2016-03-07 Matt Smith

這很有道理，但如果添加和編輯設備的UX場景不包含作爲工作集的一部分的所有者ID？

很簡單，將所有者ID和設備ID一起傳給UX。所有者ID可以是一個隱藏的價值不被接口

但如果你真的想通過非規範化的數據是幾個「連接」遠上顯示？

創建不同的查詢使用情況

對於多次更新和反向標準化爲很多表，你可以看看在新的物化視圖功能。閱讀我的博客：www.doanduyhai.com/blog/?p=1930

來源

2016-03-07 12:13:09 doanduyhai

謝謝！我對你的答案的解釋似乎暗示所有的表都需要擁有owner_id，這樣Equipment表就可以擁有owner_id，這就是它的目標嗎？ –

不**所有**表都應該有owner_id。只需將owner_id放在主鍵所需的**查詢** – doanduyhai

我猜這似乎有點容易說起來難。考慮一下公司正在改變業主的場景。公司表中有一個owner_id，我正在更新它。我唯一關心業主的其他地方是在我的OwnerEquipment表中。但爲了更新該表，我需要閱讀團隊和玩家表以獲取要更新的設備列表。這聽起來是對的嗎？這是我認爲我做錯了這一點，因爲這基本上是一個連接。我只是在做更新而不是閱讀。 –

如何使深層次結構非規範化？

回答

相關問題