思考一个问题：某个布尔值在系统中应该显式定义还是应该隐式推导？

深表同意。

有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。

你要是把人动物都放在一个表中那才叫雷人

天啊，居然有这样的业务规则，记得一个故事，大概就是，某哲学老师说，人类就是直立行走，身上没有毛的啥啥，然后学生抓来一只鸡，把毛拔光，说，这就是人？
建议把业务规则改了先，不然还是再搞一个冗余字段比较好。

深表同意。

有个应用场景就是：批量查找。在批量查找时如果没有这个字段是会死人的。

我个人赞成隐式推导，一般不建议定义布尔字段。
因为绝大多数的这种判断，都是需要进行一些比较计算的。如果设定一个字段来存这个值，那么在参与判断计算的其他字段发生变化或者计算公式变化的时候，就必须更新这个布尔值。如果考虑不到位，没有更新，那么就会造成错误。为了及时更新，编码里面判断计算的调用到处都是。只要相关字段有了变化，就得重新计算。至于什么时候读取这个字段就不知道了。也许永远不会被读取。所以从这点上说，定义一个布尔值字段是得不偿失的。既增加了大量的无用计算，又引入了忘记计算造成BUG的风险。触发器倒是可以保证不会忘记计算，但是性能损失很大。如果是频繁更新的表，触发器一多，那么插入修改的效率就非常低了。
我认为如果要定义布尔值字段，那么就要求这个字段不用任何判断计算。

我认为LZ提问的动物表问题，不应该设定是否“人”这种字段判断。而是应该使用继承关系进行处理。至于提出的程序员问题，这个不是设计问题而是管理问题。管理混乱，那么插再多的这种字段也没用。除了搞乱数据库结构，没任何好处。建议对新人采用老带新的办法。编码前一定要进行设计，搞清楚了要建哪些类、有哪些接口哪些调用再编码。最好编码前就把测试写出来。新人写完设计（当然不是那种骗客户的设计说明书）后老人一定要进行审核。确认没有重复编码和层次混乱。

最后还要说一下。LZ提出这个问题考虑的层次有点低，什么都放在了数据库层次考虑。这样会把太多的业务逻辑引入到数据库里面。建议尽可能把业务放到应用层而不是持久层。