业务处理逻辑写在程序里好还是写在SQL存储过程更好？

明亮Lucky 2017-10-20 04:38:05

一直有这个疑惑，我是写c++后端服务器的，现在的公司领导都要求尽量把业务逻辑写到存储过程里处理，程序只做通用的配置，这样一来代码很少很通用，很多时候都只要加个存储过程就解决了，这样好吗？

...全文

825 1 打赏收藏转发到动态举报

写回复

1 条回复

切换为时间正序

请发表友善的回复…

发表回复

赵4老师 2017-10-20

打赏
举报

回复

好！

Microsoft SQL Server 数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能，使您可以构建和管理用于业务的高可用和高性能的数据应用程序。黄强老师针比较稳定且较新的SQL SERVER 2012版本演示...

业务逻辑写在存储过程还是后台代码？就这个问题，要看所属的行业和所做的业务，需要区别对待。因为业务要求不一样，传统软件开发（如电信、银行、金融行业）和互联网Web开发的思维方式不一样。传统的软开行业考虑业务的稳定性、安全性、系统性能；后者主要考虑扩展性、快速迭代、高并发、低成本。下面说说两者的优势： 1 存储过程优势性能效率高因为存储过程已经预先编译，不需要经过数据库服务器解析，执行速度更快安全性好、稳定性高调用存储过程只需要参数输入，防止SQL注入，屏蔽了数据库的表结构，隐藏核心业务

SQL是写在程序里还是存储过程中好？ 1，方便性如果SQL更改返回的字段不改变时，程序可以不用改，但是这个谁说的定返回的东西不变，所以就后续维护，把SQL写在程序中对于维护是更方便些的。 2，运行速度把SQL写在程序中，就得编译之后才能正在数据库中执行SQL，如果运用了ORM，如Java中使用Hibernate的HQL时得根据对象-关系映射文件中的映射信息，把H

最近转去了做互联网开发，看到了最大的不同就是后台代码算法比较多，模块服务化，很多逻辑都写在了后台代码中，比如各种计算甚至连诸如分组排序这种SQL最擅长的功能。到底逻辑是应该写在后台程序中还是SQL中？这个话题其实没少讨论过，我这里仅想把一些看法总结下。如果这个问题交给数据库专家去回答，那么十有八九的答案是写在SQL中，理由如下。性能尽在掌控中，集群，共享存储，表分区，索引...

SQL应该负责怎么样的CURD，分组、排序、可能根据业务逻辑只是选择性查个别字段、使用SQL函数等等让不让数据库做？还是自己用编程语言(比如java、c++)写的应用程序里处理数据？实例：统计2015-03-22 ~ 2015-03-24期间全国每个城市/省份每天的访问ip量。假设查询涉及的表的数据量为S。考虑以下三种方式。做法一：在一个以天为步进单位长度来遍历2015-03-22 ~ 2015-...

15,440

社区成员

58,167

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章