最近在做一个项目，表关系比较复杂，而且以后可能会有很大扩展。我想为每一个表建立一个表征是否可用的字段，“1”为可用，“0”为禁用，默认为“1”，用户在前台所做的“删除”仅能改变此字段的值，真正的删除只能通过后台实现，请问这样做的优缺点是什么？
因为你上面说到了你们做的东西的表结构比较复杂,那么这点就很明确了。做逻辑删除（设标记）比物理删除要好的多，因为你在多表进行操作的时候一定是有关联的，如果你物理删除了这个字段，在你下次再跑程序的时候，你关联的方法会因为找不到你的这条记录而报错误，这样你的维护起来就很不好维护了。
但是逻辑删除和物理删除也要分情况，如果是末级的记录，经常更新的，为了维护起来方便可以设置成物理删除的，如果是标题类的，或者是菜单中的比较重要的关联表中的记录，那么最好就打上标记，以防以后操作中因没有了关联记录而报错误。
我不知道这些能否帮助你解决问题，但是应该会有一些帮助吧，呵呵！
优点是数据可以留档，但是缺点是维护性不高，程序变得更加复杂，数据量增大，查询效率降低。
补充优点：
数据没有被真正删除 不需要修改索引。 从某种程度上提高效率。
缺点当然是数据增多 需要定期清理。
具体看用户,如果用户很容易出错,那么加个标记是不错的.如果用户一般不会出错,或者明确要删除的,那么就直接删除好了
优点：对于数据的恢复性和安全性更好，缺点是数据库里面的冗余会增多吧！
如果是商业应用的话这种方式是正确的
因为有些数据可能删除后造成不可恢复的后果
所以可以标记一下“删除”，定期（如半年）做archive
这个要看业务的，业务是否需要逻辑删除，做某种特殊效果考虑这种方式。
不然你很容易让整个系统都是过期的数据，没有一个表是可以删除数据的。
增大的麻烦性你都可以感到恐怖。
历史数据可以考虑移动到别的表。
在一个万一怕用户删除失误需要恢复，不是还有数据库恢复功能的嘛，不用
自己吭哧吭哧吧
这个方法非常好，我发现有不少系统都是这样做的。
LZ的业务逻辑很复杂的话，删除一条记录可能会牵连到很多其他表的修改，这时如果实时操作的话很可能导致数据库并发度下降。 标记删除后可以在晚上运行一个回收数据的任务，这样可以比较好的解决残余数据的问题。
定期挪到archive里
和具体的业务有关吧
我们现在做的系统业务需求就是数据不删除,添加标记位,定期清理
我项目里面有的业务就是这样做的.用户上传或者发表的内容.一般不会直接删除.就用一个列来做标识.
数据量不大.所以暂没考虑性能问题
比方说A表中存在有BID。
你显示A表的时候需要把B表的信息显示出来。
如果你删了你的B表记录，那么你的程序要么是报错，要么是显示为空。这样子的情况做为一些数据记录的表来讲是很好的一件事情。
所以就会有active这种字段的产生。
一般用于数据档案表。
业务问题
如果真需要这么做需要考虑转档
还是根据具体的业务需要来确认吧！