iBATIS评价

这个问题在ibatis 框架中解决应该是不困难的，何苦留给使用者解决呢

如果每个字段都自己去设置默认值，我觉得实在没有任何必要性（如果是哪有，完全可以在数据库服务器端设置默认值的，何必程序去处理）。在ibatis中也可以通过动态构造SQL来实现对null值的处理（另外一种就是设置默认值），只是这种动态SQL写起来太麻烦了些。感觉用上了它，比写普通的SQL还浪费时间

但是我一直是在pojo中解决的。
举个例子可能更加能够说明问题。比如一个Book类有三个属性：书名、作者、出版日期。如果在bean中允许为空的话，比如作者为null,那么比较作者名的时候，就必须是"作者名字".equals(book.getAuthor())，而下面的写法：
book1.getAuthor().equals(book2.getAuthor())在运行时可能会抛出异常。日期也一样。
这里，我觉得最好的办法还是NullObject模式。或者说，对于String, book中得初始值就是"";

如果能够确保从bean过来的和从DB读取的字段都不会出现null，那么ibatis并不会有额外的要求。

楼上的理解有些错误了,比如讲你的例子,作者为"",空字符串,那代表什么意思?空字符串和null是完全不同的概念.数据的默认值是不能随便用的,否则很容易逻辑问题.再简单地举例,如果是datetime型,也就是书的出版日期,你怎么个设置默认值?(1900-01-01还是1970-01-01),这和null是完全不同的概念啊.
     默认值只有在业务有需求的情况下才能进行设置,而不是自我以为的去设置.另外如果一个具有四五十个属性的对象,是不是都要认为去设置默认属性呢?(每个对象都要维护那么多没有意义的空间.)这样的做法可以解决问题,但是是一个比较不好的处理问题的方式. 因为在ORM或者数据库服务器这一层都相当容易地处理这样的问题.

我认为设置""空字符串或者一些初始值也是可取的一种方法，有一些系统我见过就是基于这种not null设计出来的但他的特点是把大量例如日期型数据都使用了VARCHAR的形式存储
楼上说的也有道理，有的时候""会产生很多歧义，我也遇到过一个系统一开始是用初始值后期改成Null了，结果改的人很恼火，所有测试都要重新来一遍:(
PS:POJO的Bean还是很好处理的，写个反射遍历一下Set比较方便，自己转化STR到其他类型数据也可以自己来做，看框架是不是愿意给你做了
iBATIS比较恼火，有时用着用着就火大....，总是想，怎么这么Easy的事情都要我来做 习惯了就好多了

对于字符串而言，在model这个层次，""和null在大部分情况下都可以等价的。重要的是一致性。
datetime是个硬伤，但是这是历史遗留问题。不过对于纯日期，我都把它搞成int型了。
对于数值型变量而言，即便不给他设定Null值，它也会给出一个0值。或者说，我们已经漏过一大票的东西了，在String这个地方堵住，也没太大意思乐。

比如，假设有一个年龄字段，那么，即便数据表里面允许null，在po/vo中因为都是int,最终也只能体现为0。或者说，在这里，"不知道"已经被迫等价于0了。
此时，关键之处是找一个不会有歧义的值来表示不知道。比如绝大多数情况下，这个年龄等于0是不会发生的，所以浏览者不会有歧义(甚至可以在view层做特殊处理不显示0)。
当然，对于那类真正涉及到0岁的系统，如医院的婴幼儿管理，则需要别的缺省值或者用别的方式处理。

首先我们清楚两点，第一是null，第二是默认值，null在java中只会针对对象起作用，对于基本数据类型，本身就没有null的概念。第二，所谓的默认值，是当传入的对象为null时，我们需要处理的值（如果传入的是具体的值，比如说int的0，你又怎么知道用户不是输入0呢？请注意我这里的int是抽象的int，不是特指年龄，一个程序能确定这个int的含义是年龄还是数量还是其他什么吗?），也就是客户在不做任何修改录入情况下的值，比如金额，默认为0.0，性别默认为男，单据录入日期默认为当前日期等等，这些值是不应该存在null值的（如果存在null，那是需求分析人员说明的错误），这些是和客户的需求紧密相关的。
    我们现在要谈的问题也就是两点，对于null，我们怎么处理，究竟是设置默认值还是忽略；第二默认值的设置由谁来做。
    好，我们看第一点，任何一个所谓的默认值都是跟随客户的需求，而不是自以为是的添上自己所想的（简单如字符串，谁说""就可以代表null？一个是输入""而一个是用户不输），如果没有特殊的用户确定，自以为是的这么去做，会带来相当多误会和问题的（程序员之间，客户与开发人员之间都需要去维护这种解释，而这种解释又不是在需求中所定义），这样解决问题的方法是不合适的。第二，默认值的设置是谁定的？不是你，不是我，是客户，是系统的用户所定，默认值对它才有效果。另外数据的默认值该怎么定，数据库提供了默认值的方式，我们有必要在对象中这么去处理么？当一个对象的属性超过四五十个，是不是在javabean的构造函数中一个个设置，还是在setter方法中判断，抑或保存的时候逐个判断？好，就打这么做，那是否又想过了大量的无效数据冗余呢？一个对象的最小的大小只是和必要字段相关系，而按照楼上的做法，就要保存数以倍甚至十倍记的无意义内容。这还是一个对象，整个系统，要做这样的维护纯粹没有任何意义。
    这样的做法，我建议楼上还是好好思考一下，即算是使用ibatis（虽然我认为它处理得不好），也不是楼上这样的处理方式的（它是通过动态构造SQL语句实现）。况且一个so easy的问题，无论是通过JDBC直接赋值（就是赋null）还是通过反射过滤也好，都远远胜过于非需求的默认设值的。

首先一点，如果用默认值的方法替换NULL的做法，我的理解是有两个原则：
第一个原则是:默认值应当等同于NULL的逻辑意义（同一性），比如说输入数字的时候不输入和0的意义是相同的，不会对后面的业务逻辑计算产生影响
第二个原则是:默认值无法得到同一于NULL的时候，应该在业务逻辑范围之外的地方取值，以进行过滤，例子是日期型：19990909就是可以转换的，如果说数据库里面是""或者00000000，系统很容易过滤和识别出来
我认为这个数据库设计还是和设计方针有关，而与技术实现关系不大，iBATIS是有些缺陷，不能很好的实现各种不同的需求，如果有必要规定框架还是要用一些方法来规避为好。而数据库设计与是不是Java开发语言之类的，我觉得关系不大，能够实现业务逻辑才是最重要的。
我认同楼上的第二个讨论点，的确要考虑哪两个点上的问题。
我趋向于不使用Default Value，这样也许对数据库的依赖会大一些，而且会有些东西不能在你系统中得到解决，与数据库的偶合相对大了，你的设计的灵活性就降低了。
我想Hibernate的默认值还是要手动建立UserType，也是有自己的一定考虑的。

数据库的容量和容积还是很放心的，我是一个数据库围绕论者，我比较相信数据库能把所有的东西都作的很好，强大的数据约束配以业务对象关系能够建立庞大的系统。最后一段是我对现在公司的数据库设计发表一些不满，发发牢骚。赫赫，不是针对楼上

呵呵，楼上，没有发现你针对我什么啊？相反，我也认同你的观点的。
   不过我们讨论的不是数据库设计的问题（所以数据库中是否设计默认值也不应该去考虑）。现在的问题是这样的，用ibatis判断null比较麻烦，觉得作为一个ORM的工具不应该是这样，也就是它可以做的更好些。
   至于你说要保证默认值与null值的一致性，呵呵，这个非常准确，就是因为这需要两个方面，一个是用户的认同，第二就是程序、开发员之间需要去维护这种一致性的关系，同时这种维护是相当大的。至于容量，我不是指数据库，而是指对象的存储，对于一个只录入了四五个字段的对象，在没有特殊要求的情况下有必要去维护另外十数倍字段么？那完全是给自己添加烦恼嘛！
   呵呵，讨论到这里，也差不多了。我希望听到更多关于ibatis的评价的