正文
序列化虽然解决了一部分问题，但是臣民们很快发现了它的弱点：效率低。
Java对象少的时候还行，如果需要大规模地对Java对象进行存储、查询的时候那几乎不能用。比如说想选取 age > 28的所有Person对象，那就得把所有序列化的Person 对象都装入内存，一个个的比较年龄，这实在是太费劲了。
IO大臣这次也辙了，只好建议国王去国外考察，看看人家遇到这个问题是怎么解决的。
国王放下高傲的身段，派出了多个使团，分别出访了C++, Python, Ruby, C#... 等王国。
一个月后，使团陆续返回，带回的消息惊人得一致：使用关系数据库存储大规模数据。
“关系数据库？ ” 国王听说过这个东西，在Java帝国东边的大海上，有一个叫做数据库的岛屿，那里有几个很大的部落，好像有什么Oracle, Db2, SQLServer ,MySql 之类， 他们组成了一个联合酋长国。
IO大臣说： “关系数据库就是用类似二维表格的方式来存储数据，臣听说他们从70年代末开始就开始发展， 由于有强大的理论基础，像什么关系代数，关系演算， 现在发展的非常成熟，可以进行大规模的数据存储和查询，还可以支持我们梦寐以求的事务操作呢。奥对了，他们搞出了一个叫SQL的东西，屏蔽了具体的实现细节和各个数据库之间的差异。”
线程大臣还在记恨IO大臣一个月前的讽刺，马上柔中带刚，皮笑肉不笑地甩出一个炸弹： “这个酋长国看起来挺好啊，只是IO大臣提到他们用二维表格的方式来存储数据， 而我们这里是Java对象，好像不太匹配啊。”
国王上钩，向IO大臣发难： “ 一个是表格的行和列，一个是对象的属性，我们怎么把对象存储到表格中？”
IO大臣胸有成竹地说： “这需要我们的臣民自己写代码，把对象属性变成数据库的行/列，人家别的王国都是这么干的，这种办法还有一个很好听的名称叫Object-Relational Mapping， 只是现在这种Mapping 需要我们手工来做罢了，你要想大规模的查询和存储数据，总不能一点代价都不付出吧。 ”
国王说： "那就这么办吧，IO大臣，你去负责和数据库联合酋长国谈判，让他们和我们Java帝国协调一个接口出来，名称就叫......"
IO大臣马上接口： “Java Database Connectivity ，简称JDBC，如何？”
“好！ 就用这个名称，你去谈判一定要坚守住帝国的底线，那就是
我们只负责定义接口， 具体的JDBC实现必须由各个数据库去提供
！你要是搞不定，就别回来见我。 退朝！”
半年以后，Java帝国和数据库联合酋长国就JDBC达成一致，双方签署了正式的协议，帝国的臣民们欢欣鼓舞， 纷纷开始使用JDBC作为持久化的工具。
可是这JDBC的劣势也很明显：这是一个非常“低级”的接口，程序员需要处理太多的细节，冗余代码太多，写个简单的查询就得一大堆代码伺候，打开connection，创建statement，执行sql，遍历resultset，还得记住关闭connection，要不然会资源泄露......
