數據庫啊，數據庫！
雖然現在應用架構強調業務邏輯不依賴數據庫，僅把數據庫作為信息存儲的手段。但是國內的情況似乎還是挺以數據庫為中心的。數據庫雖然存在了多年，也算成熟了，但是很多書上其實對如何有效使用數據庫的強調很不夠。
尤其是對java而言，JDBC是java訪問數據庫的標準，也就是獨立于數據庫的。雖然如此，數據庫廠商大概不會為了jdbc去改自己的數據庫，要知道，數據庫肯定是要提供多種接口方式的，比如C。數據庫一改，這些接口很可能都要改，這就不好了，還可能因為接口做不到向下兼容得罪現有用戶。于是，成本比較低的做法，就變成了在jdbc層做手腳，也就是通常所說的“忽悠”。
有些數據庫其實不支持預編譯sql的，但是仍然支持PrepareStatement，這里就會引起使用者的困惑，不清楚它內部到底是怎么實現的。 還有些數據庫其實不支持jdbc所提供的那些事務隔離級別，或者跟jdbc規定的那些沒有嚴格對應關系。這就更令人惱火了，經常有人抱怨設置隔離級別沒有效果，大概就是這個原因所致。
數據庫還有一個很少被提及的問題，那就是并發問題中的第二類丟失更新。比如：兩個客戶端A、B對同一條訂單數據進行操作。事件序列如下：
A：打開訂單
B：打開訂單
A：保存修改
B：保存修改
aha！A的修改就很可能丟失了。不要抱怨數據庫怎么連這個都解決不了，其實并不是解決不了，而是沒有什么通用的方案，倒不如把它交給開發人員自行選擇方案的好。開發人員可以選擇樂觀鎖和悲觀鎖，一切都要根據業務情況來。
問題是，資料上邊很少提及會有這樣的情況發生，開發人員也就不曾處理過這個問題。根據我的理解，我覺得存在update操作的表都要進行這個處理，否則數據的正確性就無從保證。