以下都為個人思考總結所得，只作為拋磚引玉之說，一定會有不同意見，如果你有不同看法，歡迎拍磚。
記得剛入公司帶我的研發哥們能寫一手漂亮的 SQL,搜索準確、執行快、效率高。
配合Web項目中的查詢展示數據的需求，基本是分分鐘完成任務。
那段時間基本是仰視的態度，每天都去討教一點手寫 SQL 的要點，翻看一些 SQL 優化調整的技巧。
隨後經歷了幾個項目的打磨，不斷去調整公司的框架，發現項目中大段 SQL 出現的概率越來越小。
我不得不停下腳步，開始反思和總結出現這種現象的原因。如果你手上不忙併且感興趣，請聽我慢慢道來。
下面是一個經典的系統權限數據庫設計，作為例子來展開論述。
以下都為個人思考總結所得，只作為拋磚引玉之說，一定會有不同意見，如果你有不同看法，歡迎拍磚。
記得剛入公司帶我的研發哥們能寫一手漂亮的 SQL,搜索準確、執行快、效率高。
配合Web項目中的查詢展示數據的需求，基本是分分鐘完成任務。
那段時間基本是仰視的態度，每天都去討教一點手寫 SQL 的要點，翻看一些 SQL 優化調整的技巧。
隨後經歷了幾個項目的打磨，不斷去調整公司的框架，發現項目中大段 SQL 出現的概率越來越小。
我不得不停下腳步，開始反思和總結出現這種現象的原因。如果你手上不忙併且感興趣，請聽我慢慢道來。
下面是一個經典的系統權限數據庫設計，作為例子來展開論述。
img
組織機構、用戶、角色、菜單作為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 減少的主要原因，我們喜歡在一個面向對象的頻道去編程。
好了，就這樣吧。以上都為個人思考總結所得，只作為拋磚引玉之說，如果你有不同意見，歡迎拍磚。
來源：http://1t.click/dFC
:-D 搜索微信號（ID：芋道源碼），可以獲得各種 Java 源碼解析、原理講解、面試題、學習指南。
:-D 並且，回覆【書籍】後，可以領取筆者推薦的各種 Java 從入門到架構的 100 本書籍。
:-D 並且，回覆【技術群】後，可以加入專門討論 Java、後端、架構的技術群。
以下都為個人思考總結所得，只作為拋磚引玉之說，一定會有不同意見，如果你有不同看法，歡迎拍磚。
記得剛入公司帶我的研發哥們能寫一手漂亮的 SQL,搜索準確、執行快、效率高。
配合Web項目中的查詢展示數據的需求，基本是分分鐘完成任務。
那段時間基本是仰視的態度，每天都去討教一點手寫 SQL 的要點，翻看一些 SQL 優化調整的技巧。
隨後經歷了幾個項目的打磨，不斷去調整公司的框架，發現項目中大段 SQL 出現的概率越來越小。
我不得不停下腳步，開始反思和總結出現這種現象的原因。如果你手上不忙併且感興趣，請聽我慢慢道來。
下面是一個經典的系統權限數據庫設計，作為例子來展開論述。
img
組織機構、用戶、角色、菜單作為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 減少的主要原因，我們喜歡在一個面向對象的頻道去編程。
好了，就這樣吧。以上都為個人思考總結所得，只作為拋磚引玉之說，如果你有不同意見，歡迎拍磚。
來源：http://1t.click/dFC
:-D 搜索微信號（ID：芋道源碼），可以獲得各種 Java 源碼解析、原理講解、面試題、學習指南。
:-D 並且，回覆【書籍】後，可以領取筆者推薦的各種 Java 從入門到架構的 100 本書籍。
:-D 並且，回覆【技術群】後，可以加入專門討論 Java、後端、架構的技術群。
來吧，騷年~