为企业应用程序创建数据库时，保留创建日期有什么用
我刚刚开始专业编程，我的经理倾向于指示我在我们使用的所有数据库表中保留创建、修改和删除日期。我想知道保留这些字段供企业应用程序是否有意义。我之所以问这个问题，是因为我在网上读过的所有示例、教程、书籍都从未有过这样的字段，而且它还增加了复杂性，因为每次我必须使用实体时，我都必须确保我正在使用实体.DeleteDate == null
感谢您的建议
I have just started with professional programming and my manager tends to dictate that i keep create, modified and delete date in all database tables that we use. I want to know does it makes sense to keep these fields for enterprise application. The reason I am asking it that because all examples, tutorials i have ever read on net, books never had such fields in place and also it increases complexity because each time I have to work with entities, i have to make sure I am using entity.DeleteDate == null
Thanks for your suggestions
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这可能是一件好事。我建议您做的第一件事就是了解视图。视图只是存储的查询。 视图是您的朋友。
例如，您不必在基表中查找“删除的位置不为空”，您可以创建一个名为 viewActiveWhatever 的视图并过滤该视图，以便它只生成删除所在位置的数据不为空。请记住，观点是你的朋友。
软删除（标记为已删除）与硬删除（噗，真的不见了）。这真的会把事情搞砸，具体取决于您使用的数据结构类型。
并不是为了让这变得更加困难，但是，有时保留某些内容在更改之前的外观是很好的。因此，简单地在数据行上放置修改日期只会告诉您该行何时被更改......它不会告诉您更改了什么。
现在，如果您引用的数据称为“控制数据”，您可能需要考虑保留历史表。然后，在每次更新控制表中的记录之前，将当前数据行插入到历史表中，然后进行更新。现在，您拥有了更改内容的永久记录，并且可以随着时间的推移返回并查看所有更改。
如果您在存储过程中进行所有更新，这种记录保存并不那么困难。
This can be a good thing. The first thing I recommend you do is learn about views. Views are simply stored queries. Views are your friend.
For example instead of having to look for "Where Deleted not null" in your base table, you could create a view called viewActiveWhatever and filter the view so it only produces data where Delete is not null. Remember, views are your friend.
Soft deletes (marked as deleted) vs Hard deletes (Poof it's really gone). This can really mess things up depending on what kinda of data structure you have in place.
Not to make this any more difficult but, it sometimes is nice to preserve how something looked prior to it being changed. So, simply placing a modified date on a data row only tells you when that row was changed... it doesn't tell you what was changed.
Now if the data you are refering to is called "Control Data" you might want to consider keeping a historical table. Then before each update to a record in a control table you insert the current data row to the historical table and then make your update. Now you have a permanent record of what was changed and can go back over time and see all the changes.
If you do all your updates in stored procedures, this kind of record keeping is not that difficult.
通常最好保留所有可以保留的内容，然后将来您可能决定删除某些字段/记录，这是可能的。如果你不保留它，当它消失的时候，它就消失了，你永远无法把它找回来。如果你存储它，现在没有理由不存储它，因为空间成本几乎为零，两年后当你需要提取经理要求的审计报告时，你将获得这些数据
its generally better to keep everything you can, and then in the future you may decide to remove certain fields / records, which is possible. if you dont keep it, when its gone, its gone, and you're never getting it back. if you store it, and these days, theres no reason not to store it since space costs next to nothing, you will have the data 2 years later when you need to pull some audit report your manager is going to ask for
这取决于您的解决方案所针对的业务。但是，这不会给您带来问题。只需将此功能添加到由所有实体扩展的基类中即可。
It depends on the business your solution addresses. However, this should not cause you problems. Simply add this functionality into a base class extended by all of your entities.
迟早需要进行某种审核。软删除有时是为了设计方便，但通常是法律要求不删除任何内容。企业发展得越多，因某种原因被起诉的可能性就越大。当需要收集法律文档时，将记录保存在表中会有所帮助。
一定比例的人（~2%）会很高兴使用你的服务一段时间，然后他们会关闭（尝试删除）他们的帐户并致电 Visa/Master 卡声称欺诈。您需要记录他们的活动并将其提交给信贷人员，以便对抗该索赔；被列入信用卡处理商的“不良商家”名单是非常昂贵的。
Sooner or later, some kind of auditing is required. Soft-deletes are sometimes matter of design convenience, but often legal requirements that nothing is ever deleted. The more a business grows, the grater the likelihood that they will be sued for one reason or another. Having records preserved in tables helps when it's time to gather legal documentation.
Certain percentage of people (~2%) will be happy to use your services for a while, then they will close (try to delete) their account and call Visa/Master card to claim fraud. You will need to document their activity and submit it to the credit people in order to fight that claim; being on "bad merchant" list with credit card processors is very expensive.