问一个关于网站数据删除的问题?
此后无论做什么,我都会记住这个深刻的教训,给自己留一颗后悔药,总会在建表时留一个is_del
字段以表示是否被删除了……,所有的删除不直接物理删除,然后我就很嘚瑟,再也不怕误删了……
但是现在碰到了一个麻烦,某个字段是唯一索引的,而我暂时不想用这个数据就把它删了,当然不是真删了,用is_del
标示而已,但是问题就是我现在要添加的一个数据和这个“被删除”行里面的唯一字段重复了,导致我现在如果不真的把那个删了的话我就添加不了这行数据了。
我想到了两个解决办法:不知道合不合理:
1:删除时将要删除的数据“剪切”到另外一张“回收站临时表”
2:只剪切要删除的行的部分数据,比如上文中的唯一索引那个字段,将当前的冲突字段数据擦除,放到另外一张临时表上面,用主键对应就可以了。
我总觉得是不是我的想法有问题,总感觉欠妥,但又不知道怎么做,希望有经验的大神解答指点下哈?
回复内容:
先说背景:某日我测试时一下子删了很重要的东西,一篇重要的文章,立即后悔了,但是却发现没有“回收站”,数据表是直接物理删除的,我的内心是崩溃的……
此后无论做什么,我都会记住这个深刻的教训,给自己留一颗后悔药,总会在建表时留一个is_del
字段以表示是否被删除了……,所有的删除不直接物理删除,然后我就很嘚瑟,再也不怕误删了……
但是现在碰到了一个麻烦,某个字段是唯一索引的,而我暂时不想用这个数据就把它删了,当然不是真删了,用is_del
标示而已,但是问题就是我现在要添加的一个数据和这个“被删除”行里面的唯一字段重复了,导致我现在如果不真的把那个删了的话我就添加不了这行数据了。
我想到了两个解决办法:不知道合不合理:
1:删除时将要删除的数据“剪切”到另外一张“回收站临时表”
2:只剪切要删除的行的部分数据,比如上文中的唯一索引那个字段,将当前的冲突字段数据擦除,放到另外一张临时表上面,用主键对应就可以了。
我总觉得是不是我的想法有问题,总感觉欠妥,但又不知道怎么做,希望有经验的大神解答指点下哈?
如果要足够优化的解,那自然是移到其他表去,这样既不妨碍当前表数据,又利用当前表高效的工作。
如果图方便,可以弄个组合索引,将is_del
也纳入其中。
一般情况下 唯一索引 只能给id
nickname
之类的字段
一条记录is_del
的时候id
nickname
之类的被使用了就是被使用,不应该再出现,拿nickname
来说,这条记录被删除,应该被当作封禁而不是常规的删除,某个nickname
被删或者被封禁以后这个字段不应该再被拿出来使用。
删除的时候先把这个记录复制到到回收站
`被删除数据备份`表可以做,但是更好的做法应该是处理你的唯一索引,确定你这个字段是否真的需要唯一索引
如果不嫌麻烦就做个日志系统,所有增删改的数据都写入日志,然后如果有误操作再根据日志做回滚操作
放到另一张表里边吧,保险,而且当你查询删除数据的时候可能速度会快一些。不过我感觉放到临时删除表的时候,id应该重建了,不然你再删除相同id的数据,麻烦还是会出现。
建表的时候保留is_delete字段是一个很好的习惯。
按照你说的,你删除数据后,又要添加一个和已经删除记录的唯一索引字段相同的记录,可见你已经删除的记录在业务中应该不会在用到了。
我想到的解决方法是:
1.将唯一字段和is_delete字段一起设置成唯一索引,这种加入后面需要将删除的记录恢复使用很容易处理;
2.在插入唯一重复的记录时,将删除的记录移到history表中,这种原表更简单,不过后面要恢复以前的记录有点麻烦;
3.如果插入唯一重复记录的情况比较多,建议直接采取删除时候就移到history表中,这样插入的时候方便。
亲,windows系统的回收站难道避免了误删重要文件的结局吗?
我觉得你想的太多了,从你的故事背景就可以看出来你的立场出了问题。作为一个开发人员,你需要满足客户的要求,比如删除文章这种事情根本不是你应该做的,如果用户自己删错了东西他自己去后悔,和你有什么关系?就像咱们在这里发东西,删掉之后能找回来吗?开发人员需要为此负责吗?
日志其实是很重要的东西,但是通常使用日志不是为了找回数据,而是为了分析问题,实际上mysql本身也可以开启日志,那个可以帮助你找回数据,为什么要在php上重新搞一遍呢?
所以,我的看法是除非客户说:我们使用的时候经常删错东西,别做物理删除了,这个时候才需要考虑is_del这种方法。但是一般也要讲清楚,使用这个方式之后数据就永远不会删除了,千万别说还有一个功能可以把标记为is_del的数据真正删除,那还是解决不了经常删错东西问题。
程序不可能解决使用者犯下的错误,所以根本没必要想太多。对于有些人来说,就算你设计了is_del1,is_del2,is_delN,错删数据的事情还是会发生。
上一篇: 数据库删除语句delete有什么用?
下一篇: access查询时间段的问题,大问题.