捕获数据库中联系人信息的历史记录
我正在尝试制定一个数据模型,其中保留某些联系信息(例如电子邮件地址)的历史记录非常重要。如果我的电子邮件表中没有一个属性为空等待填写,如何捕获电子邮件地址的结束日期?
I am trying to work out a data model where it will be important to retain history of certain contact information such as email addresses. How would I capture an end date for an email address without having an attribute in my Email table sitting as a Null waiting to be filled in?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
最强大的解决方案是使用第三方日志记录工具,它可以让您记录插入、更新、删除甚至选择。但是,如果您只想要一个简单的跟踪系统,我会为当前数据创建一个表,并为历史记录创建另一个表。然后,每当进行插入或更新时,您就可以使用触发器来填充历史表。
适用于 MySQL 的第三方审核或数据库活动监控应用程序:
Idera 数据库活动监控
Hedgehog Enterprise
SQL Shark(更多的是监视工具,但可用于存储更改)
数据库审计
The most robust solution is to use a third-party logging tool that will let you log inserts, updates, deletes and even selects. However, if you just want a simply tracking system, I would create a table for the current data and another for the history. You could then use a trigger to populate the history table whenever a insert or update is made.
Third-party auditing or database actvity monitoring applications for MySQL:
Idera Database Activity Monitoring
Hedgehog Enterprise
SQL Shark ( more of a monitoring tool but could be used to store changes )
DB Audit
捕获结束日期的纯粹方法是创建一个与现有表和结束日期具有相同键的新表:
该表将位于 6NF 中。
在走这条路之前我会三思而后行,并尝试分析查询模式和数据分布。如果大多数查询需要检查 end_date,则此方法将会降低性能。您拥有的数据越密集(具有结束日期的电子邮件的百分比越高),这种方法就越糟糕。
另一方面,如果您的查询没有或很少关心结束日期,并且那些关心结束日期的查询对结束日期特别感兴趣,则上述方法通常会表现得更好。您拥有的数据越稀疏(具有结束日期的电子邮件的百分比越低),此方法的效果就越好。
The purist approach to capture the End Date would be to create a new table with the same key as the existing table and the End Date:
That table would be in 6NF.
I would think twice before going down this road, and try to analyze the query patterns and the data distribution. If most queries need to check for the end_date, this approach will have a performance penalty. The more dense data you have (high % of emails that have end date) the worse this approach will be.
On the other hand, if none or few of your queries care about the end date, and those queries that do are specifically interested in the end dates, the above approach will often perform better. The more sparse data you have (low % of emails that have end date) the better this approach will perform.