如何检查我是否只删除了所需的数据?
我有一个非常大的数据库(在 PostgreSQL 上运行),其中包含许多表,它们之间具有复杂的关系(外键、删除级联等)。 我需要从多个表中删除一些数据,但我不确定由于级联删除,真正会从数据库中删除多少数据。
如何确保我不会删除不应删除的数据?
我有一个测试数据库 - 只是真实数据库的副本,我可以在其中执行我想要的操作:)
我唯一的想法是在之前和之后转储数据库并检查它。 但看起来不太舒服。 另一个想法 - 转储数据库的一部分,正如我认为的那样,不应受到 DELETE 语句的影响,并在数据删除之前和之后检查这部分。 但我认为没有简单的方法可以做到这一点(有数百个表,删除应该可以处理其中的〜10个表)。 有什么办法可以做到吗?
还有其他想法如何解决这个问题吗?
I have a really big database (running on PostgreSQL) containing a lot of tables with sophisticated relations between them (foreign keys, on delete cascade and so on).
I need remove some data from a number of tables, but I'm not sure what amount of data will be really deleted from database due to cascade removals.
How can I check that I'll not delete data that should not be deleted?
I have a test database - just a copy of real one where I can do what I want :)
The only idea I have is dump database before and after and check it. But it not looks comfortable.
Another idea - dump part of database, that, as I think, should not be affected by my DELETE statements and check this part before and after data removal. But I see no simple ways to do it (there are hundreds of tables and removal should work with ~10 of them). Is there some way to do it?
Any other ideas how to solve the problem?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
使用 psql,启动事务,执行删除,然后运行您能想到的任何检查查询。 然后您可以回滚或提交。
Using psql, start a transaction, perform your deletes, then run whatever checking queries you can think of. You can then either rollback or commit.
如果担心的是悬空的键(即:指向已删除的记录),则在测试数据库上运行删除,然后使用查询查找现在指向无效目标的任何键。 (当你这样做时,你还可以确保不受影响的部分没有改变)
更好的解决方案是花时间规划删除级联,这样你就知道会发生什么 - 了解你的数据库如何工作是非常有价值的因此,除此特定删除之外,为此付出的努力将是有用的。
无论您在进行重大更改之前多么确定备份数据库!
If the worry is keys left dangling (i.e.: pointing to a deleted record) then run the deletion on your test database, then use queries to find any keys that now point to invalid targets. (while you're doing this you can also make sure the part that should be unaffected did not change)
A better solution would be to spend time mapping out the delete cascades so you know what to expect - knowing how your database works is pretty valuable so the effort spent on this will be useful beyond this particular deletion.
And no matter how sure you are back the DB up before doing big changes!
感谢您的解答!
Vinko,你的回答对我非常有用,我会研究它。
实际上,就我而言,比较记录删除前后的表计数并检查哪些表受其影响就足够了。
它是通过下面描述的简单命令完成的
Thanks for answers!
Vinko, your answer is very useful for me and I'll study it dipper.
actually, for my case, it was enough to compare tables counts before and after records deletion and check what tables were affected by it.
it was done by simple commands described below
您可以查询 information_schema 来绘制有关如何在数据库中定义约束的图片。 然后你就会知道删除时会发生什么。 这不仅对于本例有用,而且始终有用。
类似的东西(对于约束)
You can query the information_schema to draw yourself a picture on how the constraints are defined in the database. Then you'll know what is going to happen when you delete. This will be useful not only for this case, but always.
Something like (for constraints)