数据库啊，数据库！
虽然现在应用架构强调业务逻辑不依赖数据库，仅把数据库作为信息存储的手段。但是国内的情况似乎还是挺以数据库为中心的。数据库虽然存在了多年，也算成熟了，但是很多书上其实对如何有效使用数据库的强调很不够。
尤其是对java而言，JDBC是java访问数据库的标准，也就是独立于数据库的。虽然如此，数据库厂商大概不会为了jdbc去改自己的数据库，要知道，数据库肯定是要提供多种接口方式的，比如C。数据库一改，这些接口很可能都要改，这就不好了，还可能因为接口做不到向下兼容得罪现有用户。于是，成本比较低的做法，就变成了在jdbc层做手脚，也就是通常所说的“忽悠”。
有些数据库其实不支持预编译sql的，但是仍然支持PrepareStatement，这里就会引起使用者的困惑，不清楚它内部到底是怎么实现的。 还有些数据库其实不支持jdbc所提供的那些事务隔离级别，或者跟jdbc规定的那些没有严格对应关系。这就更令人恼火了，经常有人抱怨设置隔离级别没有效果，大概就是这个原因所致。
数据库还有一个很少被提及的问题，那就是并发问题中的第二类丢失更新。比如：两个客户端A、B对同一条订单数据进行操作。事件序列如下：
A：打开订单
B：打开订单
A：保存修改
B：保存修改
aha！A的修改就很可能丢失了。不要抱怨数据库怎么连这个都解决不了，其实并不是解决不了，而是没有什么通用的方案，倒不如把它交给开发人员自行选择方案的好。开发人员可以选择乐观锁和悲观锁，一切都要根据业务情况来。
问题是，资料上边很少提及会有这样的情况发生，开发人员也就不曾处理过这个问题。根据我的理解，我觉得存在update操作的表都要进行这个处理，否则数据的正确性就无从保证。