最近有点迷惑
由于考虑到系统的可扩展性或者说高可用性。
我个人一直不太赞成使用存储过程,因为只要存储过程里面有哪怕只有一行写操作,你都得把这个存储过程放在主库上。这样就造成了主库要做的事情太过于繁杂,cpu占用过高。
但是公司的同事(一个老程序员)特别倾向于使用存储过程,这样在修改逻辑时“不需要上线”(因为我们公司管理没那么严格,开发是有生产库权限的,他们管直接改存储过程不叫上线)。
我嘴比较笨,也不知道该怎么说服他。
难受,我该怎么办。
求园友们帮我想想怎么说服他,或者帮他说服我
我太痛苦了啊
存在即合理。不否认存储过程的一些劣势,但有时候方便是真方便。
你现在可能还没遇到过那种白天出问题,但又不能马上更新站点的场景。
可能哪天你遇到了,就会觉得,啊,我这里直接改下存储过程就行了,站点不用更新,真好。
当然了,除了这个场景也还有一些别的,就不逐个说了,有时候做法也别卡太死,没有什么是绝对的,更多的要参考团队的意见,比如这件事可以在某次部门会议上提出来,问问大家的想法,届时你自己可能会有一个更加深刻的认识,一些心结自然迎刃而解。
已经提了,年轻程序猿都赞成用ORM。老程序猿比较喜欢用存储过程,说实在的,遇见那种3000多行的存储过程我是真头大,有的存储过程还套存储过程。
还有就是当时提问题的时候太偏激了,没控制好情绪,已经买了莫生气现在天天看。
@龙葛格: 一些老系统. 老程序员维护的,基本都有存储过程的影子. 试图劝说这类人 更改新的技术方案, 无疑是要他们加班学习新的技术,但这个对工资上,没有任何提升,自然那些人不会太上心. 真的除非是程序跑不下去了,叫你们大领导或者 项目主管 跟他们反映情况,让他们统一指导下面的人 更换技术(使用ORM) 或者别的, 才可能有戏. 更换新的技术,调试,开发 测试 都需要时间,而且可能带来新的问题或者bug.
再者, 本质上能用就用,用不了 就换新的, 重做一套也许比维护原有的 更好.(这个需要你们大领导考虑)
作为一个开发人员,是没多少主动权的,能做的就是 出demo,跟领导讲清楚厉害关系,然后让领导层 做决策. 你和别的开发人员 是平级关系,甚至别人资历还比你老,凭什么听你的?
再者, 换位思考一下, 你写作文用了1000字, 别人跟你说 用文言文写,用 英语写会更xxx,你是什么想法?
老员工(老油条 ) 除非必要,否则绝对不修改源代码
@兴想事成: 有道理。想想也是,或许每个人都有自己的想法吧,不去想了。爱咋咋地吧,实在受不了了走人就是。
他是你上司或者他主导,那么他说了算。
如果主导者使用c语言,要求你用c,你也得放弃php。
任何事物都是辩证的,没有绝对。
我一般sql都不写,我习惯list.Where(t=>bList.Any(t.Name)),这样我基本不关心数据库是不是sql数据库。要优化,我也不会去手工写这个sql,这个成本 远远小于 我的人工成本,而且即使有这成本也不是个人的。所以我也不写什么什么分页查询,服务器只做一个带了限制的 iQuerable,把OData都省了,自己想怎么分页自己去Skip和Take即可。
嗯嗯,懂你的意思。我也是赞成使用ORM的。后来我放弃说服他们了,我自己的代码就按我的思路来,其他人的我就不管了,反正以后就算出了性能问题也不太可能是我的模块导致。
只是觉得这种不听劝的同事很让人恼火,我已经把几种做法的优劣还有现在系统中亟待解决的痛点都摆出来了,但还是没人关心,我觉得照这么做下去系统改版是没有效果的。
哦,忘了说,我们这次是改版现有系统,想从单体架构改成微服务的,因为老系统的所有计算任务和逻辑都放在数据库上,导致并发量稍微高一点数据库就受不了。那按我的想法如果继续使用存储过程压力还是集中在数据库上啊,改版又有什么意义呢。毕竟微服务架构本身并不能减轻数据库压力啊,它只是webserver层面的扩展呀
存储过程的优势和缺点,网上都有写。就几行字。
一般互联网高并发项目不适合用 存储过程,需要同时支持多种数据库的也不适合。
cpu占用是一直高还是 某1,2秒高然后就降下来。可能是数据库操作没有用上索引 ,没有优化。
你自己不用就行了,存储过程有些很变态,调试也很困难,
执行效率高!