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

为什么不把sql句写在jsp中那样子生产系统开发的会更快一些.

把所的有程序员都开除

让teamleader + 项目经理组成一个team

同样的时间可以干同样多的活.

顺手还能提高一下项目经理的工资.

跟打仗一个道理。战术思想都不统一，不过是一群乌合之众。
一个好的将领，统兵上万必也是进退有序，若放任你手下的士兵按自己意志行动，其必败。

数据库设计一般要求满足三范式要求，但要根据实际情况从减少业务逻辑和提高程序性能方面来说必要的冗余还是必要的。

这个贴子能不能关闭啊？  已经从一种设计理念的高度降到了代码实现的层次，没人真正回答我的问题。

也许实现会驱动我们做数据库的调整，但很少。我接触的更多的因为性能等而做的冗余。
不要说100多号人的团队，成千上万的团队也必然是在一个基本规范基础上做事情的，最基本的分层可以认为对任何人都是适应的，而数据库设计理论上只应该与持久层的实现相关。
1、lz提到的显式和隐式我认为都没问题，我更倾向于隐式。
2、若将来不再按照是否直立行走来区分人和动物了的话，再加字段其实也不迟。
3、冗余在这里需要保证和直立行走的数据一致性，这个是个难点。

另外，业务层不需要接口，在PO/POJO上补充相应方法即可的。

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

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

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

飘在天上写架构作设计
的那些人是不会明白
写代码这群人的想法的.

一般他们从教科书上了解他手下人的想法.

我建议显示定义。

理由如下：

1、那个行走方式字段只应该让人判断行走方式，不应该做其它事情，过多的判断依赖这个字段或许是bad smell。

2、从规范上来说，加一个“是人是兽”的字段本身就是一种规范，而且是不会有歧义，学习成本查找成本很低的规范，比隐式推导所依赖的规范廉价得多。

3、开发方便许多，如果系统逻辑很复杂的话，大量隐式推导是会要人命的，出错的概率大大增加。

深表同意。

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