撸一段 SQL ? 仍是撸一段代码？

   记得刚入公司带个人研发哥们能写一手漂亮的 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 减小的主要缘由，咱们喜欢在一个面向对象的频道去编程。

  好了，就这样吧。以上都为我的思考总结所得，只做为抛砖引玉之说，若是你有不一样意见，欢迎拍砖。