2
我已經爲我的項目設計了幾種不同的方式，並且我很好奇如果人們認爲某個方法更爲正確，那麼他們會有意見。SQL模式設計和規範化
該示例將涉及用戶，商店，地址和電話號碼。
實施例A
- 用戶表 - 包含所有主要用戶數據
- 用戶地址表 - 包含所有地址數據
- 用戶電話號碼錶 - 包含所有電話號碼數據
- 商店桌子模仿上述標準
保存
一旦父實體被保存，其他一切可批量插入/更新
實例B - 地址表 - 包含了所有的地址數據 - 電話號碼錶 - 包含所有電話號碼數據
- 用戶表 - 包含了所有主要的用戶數據
- 用戶地址表 - 是連接表的地址表
- 用戶電話號碼錶 - 是連接表的電話號碼錶
- 存儲表 - 反映上述標準
保存
我將通過所有地址開始交易和循環一個接一個地保存它們。獲取最後一個插入ID並將它們鏈接到相應的外部實體。
此方法強制從我可以看到使用活動記錄，並有做批量插入/更新沒有解決辦法，但大大降低的「主」表量，在數據庫
思考
隨着時間的推移，我開始相信例子B是不正確的。規範化是關於不爲他們尊敬的實體複製數據，而不是複製整個數據庫的存儲區域。
無論如何，所有的想法/意見非常感謝。 謝謝！
更多的想法
所以，我一直在思考這個多一些，這裏是我的想法
用戶和存儲在這個例子中會陷入DDD的聚合根的範疇。 這就是說，沒有父母的情況下，任何子對象都不應該存在。
在示例A中，如果您刪除用戶或在那裏存儲將無法通過外鍵刪除它，我認爲它尖叫它打破了聚合根規則。
即使電話號碼和地址在數據庫中有唯一的id，甚至可能有那些id在數據庫中被引用，但它們仍然是值對象。用戶和商店將是這種情況下的真正的實體，具有電話號碼和地址的價值對象（儘管它們具有ID）
我也在例子A中感到困惑如何使用存儲庫模式加載事物而不需要存儲庫談話對彼此。這種新的思路也解決了這一問題。