我應該如何在數據庫中存儲EAV地址歷史記錄？

爲了簡化一些...我想要了解用戶EAV數據的歷史，特別是指向地址的地方，但是消除冗餘似乎很棘手。我應該如何在數據庫中存儲EAV地址歷史記錄？

地址有自己的表。

除了用戶表和其他實體表中的標準數據外，用戶還有一些奇怪的數據。我打算將這些奇怪的用戶數據放在EAV表中。這個用戶的EAV數據還可以包含多個指向存儲在地址表中的地址的條目。

我想記錄更改的歷史記錄。

因此，當用戶地址的變化，它看起來需要做的是：

一個新的地址添加到地址表中。
舊的EAV條目現在不是指向舊地址行而是更新爲指向地址表中的新行。
換到EAV行被寫入到一個EAV歷史記錄表（將使用觸發器）

說實話這似乎並不像很多工作，但：

如若老地址表中的條目永遠以只讀方式坐在那裏？（好的，所以我的猜測是肯定的，清除舊的記錄是一個倉庫的考慮因素，但它似乎是如此... icky）。
我該如何至少重用這些地址條目？（或許通過提供基於新的用戶輸入匹配現有條目）

這一切似乎都那麼不潔淨的，並不僅僅是EAV）

來源

2011-09-15 poop-deck

如果你想跟蹤一個人的地址的歷史，然後EAV可能稍微「優雅」一個解決方案。我假設你通過EAV表示地址被分解爲字段，每個字段都是屬性。因此，如果有人移動，但留在同一個城市，他們的地址線會改變，但他們的城市，州和ZIP（可能）保持不變。

人們一直在移動。我忘記了統計數據，但每年有16％或18％的人移動。經常有業務理由要有對人們地址的審覈記錄。

如果您正在跟蹤地址的歷史記錄，我建議您最好保留基於快照的歷史記錄表並使用觸發器填充該表。你可以使用這樣的模式：

ADDRESS_HISTORY 
    person_key int 
, change_date datetime 
, address_1 nvarchar(50) 
, address_2 nvarchar(50) null 
, city  nvarchar(30) 
, state  nvarchar(2) 
, zip   nvarchar(10) 
, primary key (person_key, change_date)

當然，模式需要鏡像你自己的地址屬性結構。

這沒有任何優雅的重用，但它避免了所有的混淆，你正在摔跤這樣的重複使用自然會引起。保留每個地址的完整快照將使用一點額外的空間，但它會使實際使用歷史更容易。

來源

2011-09-15 11:42:46

是的。 EAV幾乎是最糟糕的結構，可以用作地址的理解。 –

對不起，也許有一點誤解（我已經調整了我的問題，使其更加明確）。地址已經坐在桌子上了。但該地址實例是一種奇怪的數據（可選且較少見），因此它的引用存儲在EAV表中。 like： - > - > –

對不起，我一開始並沒有跟着你。如果您的EAV數據與客戶有關，並且屬於該客戶的地址，那麼您可能會或可能不會走上正確的軌道。這取決於EAV數據以何種方式取決於地址。它是一個很難依賴的軟件嗎？它是指「客戶的帳單地址」還是指「我們發送該帳單的實際地點」 - 如果您關注我。真正的「icky」部分將清除舊數據。如果你試圖保持參照完整性，這會變得非常難看。否則，你可能是在正確的軌道上。 –

我應該如何在數據庫中存儲EAV地址歷史記錄？

回答

相關問題