数据删除问题?
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了数据删除问题?，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1925字，纯文字阅读大概需要3分钟。
内容图文
例如有个商品表，其中有个商品，已经跟其他表产生了关联，像订单表等。但是我现在要删除这个商品表，我是真的从数据库中删除吗？
如果删除了 其他的关联表该怎么处理？
如果我不删除，数据不是一直积累在那里？
我现在是添加了个字段 来表示是否删除.
你们是怎么处理这种问题的?
回复内容：
例如有个商品表，其中有个商品，已经跟其他表产生了关联，像订单表等。
但是我现在要删除这个商品表，我是真的从数据库中删除吗？
如果删除了 其他的关联表该怎么处理？
如果我不删除，数据不是一直积累在那里？
我现在是添加了个字段 来表示是否删除.
你们是怎么处理这种问题的?
如果有数据依赖的话，我建议加个 status 的字段，显示该商品是否下线。因为订单里依然需要商品的详细信息，所以不能硬删除。
以关系型数据库为例，我觉得可以这样判断，对记录 A 进行硬删除时，必须保证删除与 A 相关的子集记录，同时包含 A 信息的记录不会产生数据不一致。
例如，删帖操作：
comment <-> post <-> author
删除 post 的同时，必须要把 post 下的 comment 全部删除，但是如果 author 的发帖记录需要保存的话，这时就要保证数据的一致性了。
可以采取两种措施，第一种就是跟商品操作一样，对 post 设置字段标记，第二种就是根据需求生拷贝post 的标题，（所以当用户浏览发帖记录时还是能看到所有的回帖的标题，但是点击已删除记录时，提示该 post 已删除），生拷贝后的信息可以用一张新表保存起来，与原表相比减少了存储空间，这个操作只是为了保证数据一致性。当将来 author 信息也要被删除时，等同于 comment 对 post，这个生拷贝的信息也就可以彻底删除了。
我认为删除操作的难点就在于如何保持删除后的数据一致性问题，当然如果一开始就能设计出高范式低依赖的数据库结构那是最好不过了。
还有一种观点就是一切皆软删除，也就是整个系统没有一次真正意义上的删除，所有的历史记录全部保留，例如 git。
把商品从product表移到archived_product表, 实现数据冷热分离.
查询时使用一点小技巧, 这个是 高性能mysql 的例子:
SELECT GREATEST(@found := ?1, id) AS id, 'product' AS which_tbl
FROM product WHERE id = 1
UNION ALL
SELECT id, 'archived_product'
FROM archived_product WHERE id = 1 AND @found IS NULL
UNION ALL
SELECT 1, 'reset' FROM DUAL WHERE ( @found := NULL ) IS NOT NULL;
内容总结
以上是互联网集市为您收集整理的数据删除问题?全部内容，希望文章能够帮你解决数据删除问题?所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。