例如有个商品表,其中有个商品,已经跟其他表产生了关联,像订单表等。
但是我现在要删除这个商品表,我是真的从数据库中删除吗?
如果删除了 其他的关联表该怎么处理?
如果我不删除,数据不是一直积累在那里?
我现在是添加了个字段 来表示是否删除.
你们是怎么处理这种问题的?
例如有个商品表,其中有个商品,已经跟其他表产生了关联,像订单表等。
但是我现在要删除这个商品表,我是真的从数据库中删除吗?
如果删除了 其他的关联表该怎么处理?
如果我不删除,数据不是一直积累在那里?
我现在是添加了个字段 来表示是否删除.
你们是怎么处理这种问题的?
把商品从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;
1 回答4.2k 阅读✓ 已解决
3 回答1.9k 阅读✓ 已解决
2 回答2.3k 阅读✓ 已解决
2 回答867 阅读✓ 已解决
1 回答1.4k 阅读✓ 已解决
2 回答2.3k 阅读
1 回答720 阅读✓ 已解决
如果有数据依赖的话,我建议加个
status
的字段,显示该商品是否下线。因为订单里依然需要商品的详细信息,所以不能硬删除。以关系型数据库为例,我觉得可以这样判断,对记录
A
进行硬删除时,必须保证删除与A
相关的子集记录,同时包含A
信息的记录不会产生数据不一致。例如,删帖操作:
删除
post
的同时,必须要把post
下的comment
全部删除,但是如果author
的发帖记录需要保存的话,这时就要保证数据的一致性了。可以采取两种措施,第一种就是跟商品操作一样,对
post
设置字段标记,第二种就是根据需求生拷贝post
的标题,(所以当用户浏览发帖记录时还是能看到所有的回帖的标题,但是点击已删除记录时,提示该post
已删除),生拷贝后的信息可以用一张新表保存起来,与原表相比减少了存储空间,这个操作只是为了保证数据一致性。当将来author
信息也要被删除时,等同于comment
对post
,这个生拷贝的信息也就可以彻底删除了。我认为删除操作的难点就在于如何保持删除后的数据一致性问题,当然如果一开始就能设计出高范式低依赖的数据库结构那是最好不过了。
还有一种观点就是一切皆软删除,也就是整个系统没有一次真正意义上的删除,所有的历史记录全部保留,例如
git
。