derby数据库的嵌入式特性让人很流口水。但是，我刚打算将其用进我的项目中，却发现它没有好的分页查询方式，每次都返回所有符合条件的记录。oracle有rownum，mysql有limit，sqlserver好歹也有个top，汗啊汗，看来不爽的人还不止我一人。
derby的好处就不用我多说了吧，正因为如此，某个项目使用了derby，并从中发现了3个很让人无奈的缺陷。
最傻的缺陷：没有boolean数据类型
这个让人很无语，derby是我发现的第一个不支持boolean的数据库，在这个年代，很难想象还有数据库需要让人建立其他类型来顶替boolean，对应JDBC的boolean，derby使用的是SMALLINT，虽然这不是数据库致命的缺点，但这让数据库设计者产生很不爽的感觉。前些天Sun Tech Days上，SUN的Miss Lu告诉我，事实上derby的小组老早就已经完成了boolean类型，只是IBM到现在仍不让boolean出现在derby上，其中原因我只能说~!@#$%^&*…
最痛苦的缺陷：没有LIMIT和OFFSET子句(或相同功能的子句)
同样让人很无奈，derby测试小组声称derby的性能已经达到能容纳700G的数据，并向TB级别进发，但是这么大的数据量却没有办法让人实现数据库这一层的查询限制，每次查询的结果必定返回你的查询语句的所有结果。而且结果集也只能统统接收这些数据，然后由我们的代码在业务层实现对数据的分页。
不过值得庆幸的是，Miss Lu说他们已经在开发该功能，预计下一版本会实现，还有两个月时间，到时候大家准备数据大搬迁吧，for performance!
最搞不懂的缺陷：外键关联 ON UPDATE 只支持 NO ACTION 和 REDIRECT
三个之中这个缺陷最能让人接受，幸好 ON DELETE 还支持CASCADE，不然真的要 jump 了。但这始终还是对derby的功能上造成了影响，触发器，存储结构和业务层逻辑都能搞定，所以问题不是很大。
最后，希望其他derby用户有什么看法或见解也能告诉我，大家多多交流下。
---------------------------------------
感谢网友 的通知：
Derby db 在10.5版本后有重要更新
含分页的排序语句如：
select * FROM (select ROW_NUMBER() OVER() AS R, customer_id, zip from CUSTOMER) AS T where R>0 and R<5 order by customer_id desc;
分页查询是比较有用的特性。
