null?报错

mysql是以粗制滥造来获得急速性能，在程序的完善过程中一致性、健壮性都得到提升，但代价是性能下降，程序前后（默认）行为可能不一致应该是更严谨了。有时候一些看起来好像省事的东西，未必就是真省事。没准就是留下什么玄幻的BUG。
回复<aclass='referer'target='_blank'>@红薯:这就是代价啦。实际上原本输入NULL然后被默认值代替这种写法本身就应该算BUG。太玄幻了，语法糖不能把语句的逻辑硬改呀。但是应用逻辑会很复杂

建表规范,所有字段.

不许为null,+默认值.

好 一般默认都是0000-00-0000:00:00，或者用int的时间戳。

我从来没有这个问题

因为我用pg

而且我这里没有ORM

说好的不依赖数据库的具体实现。。。<divclass='ref'>

引用来自“mark35”的评论

mysql是以粗制滥造来获得急速性能，在程序的完善过程中一致性、健壮性都得到提升，但代价是性能下降，程序前后（默认）行为可能不一致回复<aclass='referer'target='_blank'>@mark35:我这里从来不用addslashes,都用数据库的escape方法mysql地基没打好，在自身演化（升级）过程中不但要处理新添加的功能，还要处理新功能与现有版本实现之间的兼容性。好比本来是按照计划修个两三层楼小洋房的规模打的地基，后来修到十几层楼的宫殿，当初的地基不能胜任只能修修补补来减小地下基础对上层建筑的影响。就像微软widnows一样，打补丁修复bug本身可能引入更多的bugpg地基打得好，健壮性、兼容性、一致性上面都不错历经多年的升级貌似没发现有啥坑。我觉得比较大的一个兼容处理是standard_conforming_strings这个配置（如果没使用addslashes()处理字符串不会有直接影响）此贴必火<imgsrc="http://www.oschina.net/js/ke/plugins/emoticons/images/35.gif"alt="">哈哈，你刚发现