我应该如何在数据库中存储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地址历史记录？

回答

相关问题