記得剛入公司帶我的研發哥們能寫一手漂亮的 SQL,搜索准確、執行快、效率高。
配合Web項目中的查詢展示數據的需求，基本是分分鐘完成任務。
那段時間基本是仰視的態度，每天都去討教一點手寫 SQL 的要點，翻看一些 SQL 優化調整的技巧。
隨著積累和實踐，SQL 水平提高的很快，同時也寫了很多，有興趣的可以看看：http://www.cnblogs.com/
隨後經歷了幾個項目的打磨，不斷去調整公司的框架，發現項目中大段 SQL 出現的概率越來越小。
我不得不停下腳步，開始反思和總結出現這種現象的原因。如果你手上不忙並且感興趣，請聽我慢慢道來。
下面是一個經典的系統權限數據庫設計，作為例子來展開論述。
組織機構、用戶、角色、菜單作為4個主要設計對象，添加三張兩兩關系映射表。
能很好的做到水平和縱向擴展，其中主要設計對象我只添加了幾個需要的字段。
該設計完全可以引入到你的項目中，根據項目實際使用人群和需求添加必要字段。
然後配合 Shiro 或者 Spring -Security 能很完美的解決組織用戶角色菜單的權限問題。
言歸正傳，項目需求中有這個一個要求，需要推送當前用戶所有的菜單項，SQL寫法。
select a.uuid,a.name
from menu a
left join role_menu b
on a.uuid = b.menuid
left join role_user c
on b.roleid = c.roleid
where c.userid = '用戶uuid';
你需要在數據庫中執行好，粘貼到你的代碼中，使用數據訪問對象去數據庫執行該SQL獲取數據。
下面看段相同邏輯的面向對象代碼邏輯。
RoleUserPO roleUserPO = roleService.findUserRoleByUserId("用戶ID");
if (roleUserPO == null) {
return "當前用戶沒有設置角色！";
}
List<RoleMenuPO> roleMenuPOs = roleService.findRoleMenusByRoleId(roleUserPO.getRoleid());
if (roleMenuPOs == null) {
return "當用戶所在角色沒有設置菜單！";
}
List<MenuPO> menuPOLis = new ArrayList<MenuPO>();
for (RoleMenuPO roleMenuPO : roleMenuPOs) {
menuPOLis.add(menuService.findMenuById(roleMenuPO.getMenuid()));
}
return menuPOLis;
上面這例子放在這裡這樣一對比是不是有感覺了，如果還不夠強烈請在往下看看。
項目需求中同樣也有一個這樣的要求，需要羅列特定角色在特定部門下的用戶，SQL 寫法。
select a.*
from user a
LEFT JOIN role_user b
on a.UUID = b.userid
LEFT JOIN orga_user c
on a.uuid = c.userid
where b.ROLEID = 'c9845b33973511e6acede16e8241c0fe'
and c.ORGAID = '75284c22973211e6acede16e8241c0fe'
同樣撸段相同邏輯的面向對象代碼邏輯。
List<UserPO> userPO1s = roleService.findUsersByRoleId("角色ID");
if (userPO1s == null) {
return "當前角色沒有添加用戶！";
}
List<UserPO> userPO2s = orgaService.findUsersByOrgaId("組織機構ID");
if (userPO2s == null) {
return "當前機構沒有添加用戶！";
}
List<UserPO> userPOList = new ArrayList<UserPO>();
for (UserPO userPO1 : userPO1s) {
for (UserPO userPO2 : userPO2s) {
if (userPO1.getUuid().equals(userPO2.getUuid())) {
userPOList.add(userPO1);
break;
}
}
}
return userPOList;
有沒有感覺出面向對象代碼邏輯不僅讀起來簡單，而且能很清楚的提示出錯的原因。
而且現在主流的數據庫還是面向關系的，而編程語言已經從面向過程發展為面向對象。
也就是說兩者完全不搭調，也就是現在 ORM 框架不斷壯大的原因，編程中需要將數據表作為對象去對待和處理。
代碼中出現大段 SQL 與面向對象的設計思路完全是背道而馳。
如果查詢 SQL 出現問題，將後台打印的 SQL 粘貼到 SQL 執行工具中去執行，分析原因，兩個工具切來切去，你不覺得費勁麼？
這應該就是後續我接觸的項目，SQL 減少的主要原因，我們喜歡在一個面向對象的頻道去編程。
好了，就這樣吧。以上都為個人思考總結所得，只作為拋磚引玉之說，如果你有不同意見，歡迎拍磚。
