?點擊上方?好好學java?，選擇?星標?公眾號

重磅資訊、干貨，第一時間送達 今日推薦：2020 年最棒的 9 個 Java 框架，哪個最香？個人原創+1博客：點擊前往，查看更多 作者：Orson 鏈接：cnblogs.com/java-class/p/5985916.html

記得剛入公司帶我的研發哥們能寫一手漂亮的 SQL,搜索準確、執行快、效率高。

配合Web項目中的查詢展示數據的需求，基本是分分鐘完成任務。

那段時間基本是仰視的態度，每天都去討教一點手寫 SQL 的要點，翻看一些 SQL 優化調整的技巧。

隨著積累和實踐，SQL 水平提高的很快，同時也寫了很多。

隨后經歷了幾個項目的打磨，不斷去調整公司的框架，發現項目中大段 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 減少的主要原因，我們喜歡在一個面向對象的頻道去編程。

好了，就這樣吧。以上都為個人思考總結所得，只作為拋磚引玉之說，如果你有不同意見，歡迎拍磚。

總結

以上是生活随笔為你收集整理的撸一段 SQL ? 还是撸一段代码？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。