做外贸没有网站需要什么条件,容县网站开发,火车头wordpress,织梦个人网站模版点击上面“蓝字”关注#xff0c;带你看好电影菜菜哥#xff0c;我新接手了一个项目#xff0c;看的我头疼呀业务有这么复杂呀#xff1f;不是的#xff0c;这个老项目完全是用存储过程写的#xff0c;每个存储过程都好几百行这样呀#xff0c;是够头疼的~有没有办法帮我… 点击上面“蓝字”关注带你看好电影菜菜哥我新接手了一个项目看的我头疼呀业务有这么复杂呀不是的这个老项目完全是用存储过程写的每个存储过程都好几百行这样呀是够头疼的~有没有办法帮我了解业务一下碰到这样的情况我真帮不了你了你可以多埋怨几句做的那个人~~~存储过程存储过程Stored Procedure是在大型数据库系统中一组为了完成特定功能的SQL 语句集它存储在数据库中一次编译后永久有效用户通过指定存储过程的名字并给出参数如果该存储过程带有参数来执行它。存储过程是数据库中的一个重要对象。优势1. 可以减少程序在调用DB时候的信息传输量其实减少的只有Request的时候2. 存储过程是预先优化和预编译的节省每次运行编译的时间所以一般情况下认为存储过程的性能是优于sql语句的。3. 对调用者可以隐藏数据库的复杂性将数据组装的过程封装。4. 参数化的存储过程可以防止SQL注入式攻击而且可以将Grant、Deny以及Revoke权限应用于存储过程。5. 如果业务开发中数据人员和业务代码人员是分离的业务人员可以不用关心数据直接调用存储过程更加面向分层开发设计理念。劣势1. 存储过程这种“一次优化多次使用”的策略节省了每次执行时候编译的时间但也是该策略导致了一个致命的缺点可能会使用错误的执行计划。2. 存储过程难以调试虽然有些DB提供了调试功能但是一般的账号根本就没有那种权限更何况线上的数据库不可能会给你调试权限的再进一步就算能调试效果也比程序的调试效果要差很多。3. 可移植性差当碰到切换数据种类的时候存储过程基本就会歇菜。4. 如果业务数据模型有变动存储过程必须跟着业务代码一起更改如果是大型项目这种改动是空前的是要命的。不推荐存储过程以上存储过程的优缺点你随便一下网络就可能查到表面看来存储过程的优势还是不少的这也说明为什么老一辈程序员有很多喜欢写存储过程。但是随着软件行业业务日益复杂化存储过程现在在复杂业务面前其实有点有心无力。菜菜在业务中并不推荐使用存储过程,辩驳请留言。1. 采用存储过程操作数据在网络数据量传输上确实比直接使用sql语句要少很多但这通常并不是操作数据系统性能的瓶颈在一次操作数据的过程中假设用时100毫秒采用存储过程节省数据传输时间0.5毫秒就算是5毫秒我觉得这点时间基本可以忽略。2. 存储过程是只优化一次的这有时候恰恰是个缺陷。有的时候随着数据量的增加或者数据结构的变化原来存储过程选择的执行计划也许并不是最优的了所以这个时候需要手动干预或者重新编译了而什么时候执行计划不是最优的了这个平衡点预先无法知晓这就导致了有些应用突然会变慢程序员处于懵逼的状态。3. 存储过程确实可以对调用方隐藏数据库的细节但是这种业务代码人员和数据库设计人员是两个团队的情况又有多少呢如果真是两个团队那业务就需要两个团队来理解和沟通我想沟通的成本也一定很高而且分歧更容易产生。菜菜认为数据库就应该做它最擅长的事情存储相关。我不止一次的看过把业务写在存储过程的情况程序代码层面真是薄薄的贫血层就是一个数据的透传。我不赞同这种写法因为我就接手过这样的程序令我头疼的不是业务而是看着好几千行的存储过程熟悉业务关键还没有调试的权限线上更不能调试。一个业务系统的设计往往需要你从数据库的层面抽离出来把主要精力放在业务模型的设计上在程序层面体现业务逻辑而不是把业务逻辑都交给数据层面的管理者。前几天我排查过一个“Bug”存储过程是输入参数是一个主键id的列表字符串长度居然是 nvarcharmax主要功能是根据id列表查询数据。我想说的是就算你是max的长度也有超长的可能性发生因为业务方传输什么参数参数什么长度是你DB无法控制的所以这类的业务一定要放在程序中做处理而不是怀着侥幸心里丢给DB。如果是抱着存储过程性能高的心态的话我到时觉你这是误入歧途菜菜认为存储过程从来都不是提高性能的关键反而系统的架构缓存的设计数据一致性更是系统关键问题。存储过程通常是一种解决方案但是通常情况下不是唯一的解决方案在选择存储过程作为方案前请确保他们是正确的选择。最后秀一波存储过程吧THE END●程序员修神之路--问世间异步为何物●程序员修神之路--提高网站的吞吐量?●程序员修神之路--?分布式高并发下Actor模型如此优秀?●程序员过关斩将--论商品促销代码的优雅性●程序员过关斩将--请不要随便修改基类●程序员过关斩将--你的面向接口编程一定对吗●程序员修神之路--高并发下为什么更喜欢进程内缓存●程序员修神之路--高并发优雅的做限流
