DELPHI盒子
!实时搜索: 盒子论坛 | 注册用户 | 修改信息 | 退出
检举帖 | 全文检索 | 关闭广告 | 捐赠
技术论坛
 用户名
 密  码
自动登陆(30天有效)
忘了密码
≡技术区≡
DELPHI技术
lazarus/fpc/Free Pascal
移动应用开发
Web应用开发
数据库专区
报表专区
网络通讯
开源项目
论坛精华贴
≡发布区≡
发布代码
发布控件
文档资料
经典工具
≡事务区≡
网站意见
盒子之家
招聘应聘
信息交换
论坛信息
最新加入: webb123
今日帖子: 1
在线用户: 1
导航: 论坛 -> DELPHI技术 斑竹:liumazi,sephil  
作者:
男 inbreak (入侵) ★☆☆☆☆ -
盒子活跃会员
2018/3/2 8:53:01
标题:
有人告诉我,写数据库软件别用存储过程;我相当的纳闷。 浏览:2554
加入我的收藏
楼主: 写数据库软件,很多人说,不要用存储过程;

可是以实在想不通,不用存储过程,如何处理一些数据;

举个例子(一个ERP行业的软件,关于材料收发存);

要用到的基础表:

1、材料有一个表,保存着与材料相关的各种属于;

2、供应商也类似;

3、员工档案

4、材料资料表还用到的各种基础表(材料类别、税率、存储仓库等)

员工的录入:

1、材料购买申请;

2、供应商的报价;

3、正式采购订单;

4、采购入库单(入库的数据与金额不一定与采购订单的相同)

5、生产领料;

6、产品送货;

好了,一个简单的统计来了;

比如现在是:2018年2月;

现在要统计2018年2月的,,上月存结存产品 ,本月入库,本月出库,本月结存 产品的的材料价格;

产品入库单可以获取工程单号,根据工程单号 可以从 生产领料中获取该工程单的领料,

入库还要部分入库的情况,所以计算所有材料价值,还得按比例计算出来;

同一张工程单可能会生产多个产品,统一领料,所以也得按相关的比例算出来;

得到的材料后,还按该材料的入库批次品找到供应商相关信息,扣除税率;(不同批次的材料,价值是不同的)

如果是出口产品还要再根据材料类别与海关账薄的合同比对。由于海关记录的是重量,而公司生产记录的数量,

进口的材料很多是使用美元结算的,还要按材料买时的汇率计算为人民币。。


我光用存储过程写都要上千行的代码(有效代码);

我想象不出来,不用存储过程,把数据读取前台后在客户端完成这些东西 情况会是如何的?
----------------------------------------------
我是菜鸟,己经搞了十多年了,但是我仍然很菜。
作者:
男 zhangpuqing (pupu) ★☆☆☆☆ -
普通会员
2018/3/2 9:00:03
1楼: 不能一概而论,该用的时候还是要用.但你举的例跟用不用没有太大关系.
----------------------------------------------
-
作者:
男 veryp (veryp) ★☆☆☆☆ -
盒子活跃会员
2018/3/2 9:06:22
1楼: ebs这些可以说是存储过程写就的,说不用存储过程的都是互联网公司,应用场景不同,适用的技术就不同,这根本就没有好纠结的。现在技术直接的连接这么方便,强行的排他是非常愚蠢的。
----------------------------------------------
-
作者:
男 lzj7015 (lzj) ★☆☆☆☆ -
普通会员
2018/3/2 9:22:29
2楼: 不少人持同样的观点:不使用存储过程。
用还是不用,应视实情而定。存储过程在服务器端执行,加重服务器端负载。服务器同时连接的客户端数少于20个、交互频次不高、涉及面不广、进行的处理较为简便、网络传输的数据量不大时,可以使用存储过程,其他情形,不用为好。
楼主列举的需实现的功能,与是否使用存储过程无紧密相关性。据我的观点,这些功能应为所开发的数据库客户端实现,不宜于使用存储过程来实现。现在绝大多数常用的编程语言、内置库所能实现的功能应强过数据库SQL语言存储过程能实现的功能。
以上意见,仅供参考。
----------------------------------------------
-
作者:
男 jfhyn (贺兰之边) ★☆☆☆☆ -
普通会员
2018/3/2 10:03:55
3楼: 呵呵,Delphi的主要功能是用来做什么的,数据库应用开发吧,有多少客户端,大家心里没B点数吗?
看看项目的应用场景,有多少客户端,用不用存储过程,不就一目了然了吗?
数据库应用软件,不用数据库的应用特性,还叫数据库开发软件?
SQLServer,Oracle的存储过程,只是用来兼容和摆设的?提倡不用存储过程的人比数据库厂商还NB?
SQLServer,Oracle的大客户哪一个不用存储过程?
----------------------------------------------
-
作者:
男 hardnut (麦轲数据管家) ★☆☆☆☆ -
普通会员
2018/3/2 10:12:21
4楼: 大型数据处理应用,如EBS之类的,不用存储过程, 硬件投入,网络带宽至少增加几倍都不一定能达到同样的性能。
----------------------------------------------
UniKeeper V10.40 -- 您最贴心的个人数据管理助手
作者:
男 lzj7015 (lzj) ★☆☆☆☆ -
普通会员
2018/3/2 11:03:09
5楼: 几年前曾在北京参加甲骨文公司举行的 Oracle 新产品推介会,主讲的软件商代表、印度裔专家也持慎用存储过程的观点。
----------------------------------------------
-
作者:
男 blacktulip (blacktulip) ★☆☆☆☆ -
盒子活跃会员
2018/3/2 11:16:37
6楼: 慎用,又没有让你不用。
----------------------------------------------
-
作者:
男 luckyrandom (luckyrandom) ★☆☆☆☆ -
普通会员
2018/3/2 11:17:49
6楼: 不能因咽废食,正确的场景正确的使用就好
更多的人非技术原因,比如开发负责人喜欢把所有代码都集成CODE里
或者又没有DBA,团队对SP缺乏认识

专家说考试时别中举人,否则可能像范进一样发疯
----------------------------------------------
SQL SERVER DBA QQ:315054403 曾经的Delphier  缘在上海
作者:
男 sczhyq (旺财) ★☆☆☆☆ -
普通会员
2018/3/2 12:14:40
7楼: ORACLE 似乎修改数据与返回记录不能在同一个存储过程中

MSSQL SYBASE 都是可以的
----------------------------------------------
我84砖家
作者:
男 luwakin (luwakin) ★☆☆☆☆ -
普通会员
2018/3/2 12:18:07
8楼: 1.能解决问题就可以,不然发明这个干嘛
2.一般数据库定时作业时,用存储过程比较多
3.有些过程速度要求比较高,也会用存储过程实现
4.我们有些非主要业务,发现数据不准确了,为了不改前端,直接表加前触发器的情况都有
----------------------------------------------
-
作者:
男 bmsr (白忙剩人) ★☆☆☆☆ -
普通会员
2018/3/2 14:39:00
9楼: 存储过程主要优点:
1.效率高,特别是复杂的数据库数据处理,大多是毫秒级的,而若网络来回传输,则是秒级甚至是10秒级的
2.数据一致性好,比如一些唯一序号的生成,交给数据库存储过程,理论上就不会又重复,而在服务端(或客户端),若不只一个服务端时,那需要付出额外的规则规划才能实现.且要保证给服务端配置时不能出错.
3.可以容易的改变应用逻辑,而不用重写程序.
4.可以使用数据库各种高级功能,对数据进行快捷处理.大大降低应用(服务)程序的复杂度.
主要缺点:
1.由于每种数据库的语言格式不统一,深度依赖数据库的系统,将很难简单的移植到其它种类的数据库.这就在一些实际应用中必须使用客户指定数据库的项目造成了很大的障碍.
2.对数据库管理员dba和数据库开发员DD的要求较高.不同的数据库技能还不能完全通用.这就为小项目小组在数据库移植时带来了巨大的阻碍
----------------------------------------------
http://blog.sina.com.cn/bmsrnote
作者:
男 tiez (骑牛夜旅) ★☆☆☆☆ -
普通会员
2018/3/2 15:07:23
9楼:   存储过程比起程序处理的优势是不用做大量的数据传递,相应的,一个数据操作需要对大量数据集进行特异性的参照和处理就需要用到存储过程。

  相反,如果一个数据操作不参照大量数据集或不同时对大量数据进行处理就最好不用存储过程。

  这里有一个数据集在哪里扎口的问题。在设计数据结构时除了要依照科学的架构模式和业务需求外,还要考虑这些数据在处理和参照时更高效的问题。比如在对可能进行大批量操作的数据进行处理时,需要进行涉及更多表的大量数据的特异判断,迫使你使用不需要进行大量数据传递的本地化处理方法----存储过程来进行操作。这种方式本身就带来了非常严重的问题。1、大量数据往往代表表级锁。2、多表参照代表多张表的锁3、复杂的特异判断往往代表在存储过程内使用的光标(表级锁、长时程)。现在如果你的程序还要满足各种不同复杂业务的高并发的情况的话,那么主体架构都依赖这种方式那你还要奢望系统不会死锁吗?

  所以,在进行整体性的系统设计时,你要考虑在哪些点把数据集进行扎口,利用一些特殊的中间表或表结构把数据在某些业务处理的关键点收束数据范围,这样使业务处理时可以使用较简单的语句或较小的数据传递量,这样就可以在客户端处理数据了。

  但是,由于数据结构和真实业务中的实体属性上有一定的差距,其实表结构往往是无法简单直接的映射业务对象的。
  所以,我们为了更直观完整的操作数据,往往开发应用服务器。应用服务器和数据库服务器有高效的传输网络或就在一台物理设备中。应用服务器把数据库中存放在多张表中的业务对象集中起来并在应用服务器中存成列表。列表或其中元素发生变更时推送到客户端或通知客户端来更新。大量的复杂业务操作在应用服务器中就遍历计算完毕了,最终的结果只在瞬间提交数据库。

  这种操作方式需要更多的开发经验和更多的开发量,对寄希望于在界面上使用几个表格式编辑就完成所有开发从而在较短时间内完成项目或看到成果的人来说往往是可望而不可及的,boss对此也缺乏耐心。所以说,先根据业务设计核心的几张表,马上做界面开发和表格编辑界面,大量使用存储过程和触发器解决复杂问题,客户单位现场开发,做大量数据报表或随着加入的业务越来越多发现问题,增加业务越来越难,最后应用系统频频死锁,解锁丢失数据,这套流程在很多小公司到处可见。

  兄弟们,不是你们聪明努力,也不是你们不钻研技术,而是无论多好的预设结构都是有承载上限的,在设计初期就只考虑较少内容的框架随着后期加入业务增多必然会接近效能和可靠性的上限。boss早期盯得越紧,开发人员经验越少系统架构的承载性往往就越低。你们需要从较少功能但承载性很高的技术方案入手,先用几个小项目练手,熟悉套路后再考虑做业务范围很大的项目。把业务中并发性高、相关性高、实时性要求高的对象放到应用服务中处理,并发性低相关性低数据量大的只涉及几张表的简单运算放到在存储过程中处理。这样可以取得开发量上的平衡。

  大家要知道,有些复杂的系统架构可能在解决小问题上显得冗余低效,但却是你熟悉套路的必要手段。不先把路走熟了,掌握几套针对不同场景的解决方案,你碰到较大项目时根本无法改变开发方法。只能用原有的承载性低的架构去糊弄眼前,最后泥足深陷焦头烂额。

          个人浅见,不喜勿喷。
----------------------------------------------
-
作者:
男 iamdream (银河恒久远,梦想无止境!) ★☆☆☆☆ -
大贡献会员
2018/3/2 15:14:35
10楼: 同意楼上的经验之谈。个人感觉大的存储过程调试起来真心麻烦,后期修改维护的成本很高,尤其是时间久了或换了人,绝对是件折磨人的事。
----------------------------------------------
-广袤璀璨的银河,永无止境的梦想(梦无止境游银河) 博客挂了……
作者:
男 luckyrandom (luckyrandom) ★☆☆☆☆ -
普通会员
2018/3/2 15:23:55
11楼: 使用SP倒不是说减少数据传递,在客户端直接发送SQL也一样,只是相当于封装而已
对于并发不高的,减少编译什么的倒体现不出什么差别
----------------------------------------------
SQL SERVER DBA QQ:315054403 曾经的Delphier  缘在上海
作者:
男 luckyrandom (luckyrandom) ★☆☆☆☆ -
普通会员
2018/3/2 15:27:12
12楼: 做过开发传统工厂里ERP开发,业务逻辑、报表都由SP、Trigger实现
也做过互联网应用DBA,现公司做SaaS ERP,统一不用SP、Trigger

就是个取舍、选择,或者说偏好也可,当然,现实中也会含有些偏见
----------------------------------------------
SQL SERVER DBA QQ:315054403 曾经的Delphier  缘在上海
作者:
男 tiez (骑牛夜旅) ★☆☆☆☆ -
普通会员
2018/3/2 15:32:30
10楼:
刚刚看了一下“bmsr (白忙剩人)”的贴,第2条说唯一序号由存储过程生成,这点大家要正确理解啊。有两种情况可由存储过程生成:1、由参照多方数据生成特定格式序号的,可调用存储过程生成,生成后马上返回给序号需求方。最终效果就像oracle中的取序列号一样。取过后要马上记录并增长。2、大量数据由存储过程生成时同步生成序号。这些序号不需要马上推送到客户端。
总之说来如果是进行界面数据输入情况下,数据生成时就应先取得序号,这样才能使用序号关联多表事务提交。不要把数据打包,提交存储过程保存时生成序号。
我们采用的方法一般是GUID做主键,有时序字段保证有些界面要按输入顺序显示防止聚簇索引的影响,有后生成的序号应付某些有序号格式强迫症的人,有排序字段应付一些不管先输后输一定要手动排好看才行的人,有有较性标记保证记录不会被真删除带来的关联性问题。有时还要设定定期清理清理某些过期的大存储量的字段的值或整行过期了都清理。
----------------------------------------------
-
作者:
男 kenliaoliao (ben) ★☆☆☆☆ -
普通会员
2018/3/2 16:55:01
13楼: 你那个ERP很多地方是要用到过程的,除非业务逻辑很复杂不适合用过程,
但有时复杂的业务中也有些简单且较固定的部分,这些也是可以用过程来实现的。
做ERP、MES等制造行业用的大型管理系统绝对会用到存储过程。
不说别的这些系统的报表系统绝对是用过程从生产库中抓数据到报表库中的。

我只听说过少用或别用触发器的,没听说过别用存储过程的。
----------------------------------------------
-
作者:
男 fausten (fausten) ★☆☆☆☆ -
盒子活跃会员
2018/3/2 22:54:34
14楼: 不用,写个服务程序代替
----------------------------------------------
-
作者:
男 ultramund (ultramund) ★☆☆☆☆ -
普通会员
2018/3/3 15:49:15
15楼: 楼主,有人告诉我你欠我一百万,你什么时候还钱?
有人告诉你就是真的了?对于复杂的业务逻辑,有时一个存储过程就好几千行,执行效率远胜客户端反复与服务器交互。我不光用SQL脚本写存储过程,经常还用C#写存储过程或函数,因为有的SQL未必写得出来,或者你不想让别人知道你如何实现的。
不是慎用存储过程,当你技术足够牛,用啥都可以,我经常触发器都用,比如自动记录整个系统的操作日志,这个没有比用触发器更好用的了。技术不到家如果用了,确实会让系统很不稳定。
----------------------------------------------
QQ:56524722 老衲决定重出江湖。
作者:
男 aknightchen (.) ★☆☆☆☆ -
盒子活跃会员
2018/3/5 13:41:56
16楼: 一般来说: 如果你普遍客户都是用SQLSERVER,那我建议你直接单选这一个数据库,

结合使用存储过程,你的程序效率会大大提高。

并且,你只有一种数据库, 程序测试也会简单化。
----------------------------------------------
...
作者:
男 baifafa (白花花) ★☆☆☆☆ -
盒子活跃会员
2018/3/5 17:06:22
17楼: 个人认为,能用存储过程的尽量用,怕不安全可以加些条件
----------------------------------------------
没有比没有更没有
作者:
男 mousesoft (MouseSoft) ★☆☆☆☆ -
盒子活跃会员
2018/3/5 17:21:11
18楼: 我个人认为能不用尽量不用,存储过程是DBA用的,程序尽量不要用;DBA主要是在脱离程序维护数据库的情况下用;程序员写程序也用的话,对于项目的整体结构考虑真不好;
----------------------------------------------
-
作者:
男 cgzcgb (cgzcgb) ★☆☆☆☆ -
普通会员
2018/3/5 18:42:50
19楼: 这个问题需要辩证的来分析,如果是个相对独立的项目未来也没有太高的并发那就无所谓,但是对于互联网应用就不同了,当数据量或并发到达一定量级的时候,分布式数据库框架是必然的选择,那么如果你的项目中有大量存储过程,那就会是个很麻烦的事情。
----------------------------------------------
-
作者:
男 nevergrief (孤独骑士) ★☆☆☆☆ -
盒子活跃会员
2018/3/5 18:49:25
20楼: 我了解的一个项目,几乎全部使用存储过程。即使自己觉得写SQL很方便了,但还是得按照项目要求全部改成了存储过程。感觉最大好处是,安全,并且服务器控制的更多一些。尤其是需要改动业务的时候,客户端exe一个字不用改。
----------------------------------------------
只有偏执狂才能生存!
作者:
男 err0rc0de (code) ▲▲▲▲△ -
普通会员
2018/3/5 21:16:40
21楼: 估计不同意用SP的,是用了啥啥框架什么的,里面有表的反射机制,如果用了SP,会破坏或者框架不知如何写了。特别是一些JAVA里面的框架的。

用了框架,有些工作是轻松了,但不一定合适全局,或局部,但很多时候,我们写码时,是为了套用已有的代码结构,强行使用,不说不能用、不合用,最简单的,学会类封装后,啥都要弄个class,明明写个函数就完事了。

度的把控是开发者功力和素质的体现,代码只是展现出来而已。
----------------------------------------------
-
作者:
男 lzj7015 (lzj) ★☆☆☆☆ -
普通会员
2018/3/6 8:14:15
22楼: 曾主持大型国际机场安检系统开发,在事务模型验证阶段,曾使用存储过程实现与数据库服务器相关的大部分业务规则,服务器延宕严重,不可行。
切记:存储过程在服务器端执行,将增加服务器负载。
----------------------------------------------
-
作者:
男 kenliaoliao (ben) ★☆☆☆☆ -
普通会员
2018/3/6 15:18:06
23楼: @lzj7015 (lzj)
切记:存储过程在服务器端执行,将增加服务器负载。
你这句话说的真有水平。好像不用过程负载量就会在客户端而不在数据库服务器一样。
----------------------------------------------
-
作者:
男 lzj7015 (lzj) ★☆☆☆☆ -
普通会员
2018/3/6 15:38:38
24楼: 请参见同一楼我的第一条回贴。
表述有不明晰之处,改为:切记,存储过程在服务器端执行,实现了较多业务规则的存储过程将较为明显地增加服务器负载。
----------------------------------------------
-
作者:
男 hardnut (麦轲数据管家) ★☆☆☆☆ -
普通会员
2018/3/6 18:33:10
25楼: 复杂业务逻辑必然涉及到大量的数据操作, 不使用存储过程只有两条硬理由: 1.不想绑定到某个特定的数据库 2.没有这方面的人才  其它理由都很牵强.
----------------------------------------------
UniKeeper V10.40 -- 您最贴心的个人数据管理助手
作者:
男 luckyrandom (luckyrandom) ★☆☆☆☆ -
普通会员
2018/3/7 15:18:54
26楼: 认同楼上
多数应用都没考虑和需要要适配多数据库
没DB人才是最普遍和主要的因素,发出这个“疑惑或经验”的人多数也不是玩DB的或者说不熟悉DB的
----------------------------------------------
SQL SERVER DBA QQ:315054403 曾经的Delphier  缘在上海
作者:
男 luckyrandom (luckyrandom) ★☆☆☆☆ -
普通会员
2018/3/7 15:22:42
27楼: 也有些其他因素,比如在一个比较大的企业里,DBA跟开发团队完全是独立的情况,若要部署SP,必须提交DBA执行,作为开发团队就不乐意走这个流程了(麻烦、耗时)
----------------------------------------------
SQL SERVER DBA QQ:315054403 曾经的Delphier  缘在上海
作者:
男 veryp (veryp) ★☆☆☆☆ -
盒子活跃会员
2018/3/14 9:26:14
28楼:
也有些其他因素,比如在一个比较大的企业里,DBA跟开发团队完全是独立的情况,若要部署SP,必须提交DBA执行,作为开发团队就不乐意走这个流程了(麻烦、耗时)


这确实是一个非常重要的考虑,所有的技术问题都是政治问题,这其中还有出了问题后的分责和kpi的划分问题。
----------------------------------------------
-
作者:
男 joesyuan (joes) ★☆☆☆☆ -
盒子活跃会员
2018/3/16 16:32:11
29楼: SP做开发确实方便,无论减少数据传输量还是保证数据一致性都很容易。
缺点就是SP的时间不可控性,对高并发应用不适合。
个人看法:
C/S或企业内的B/S程序用SP,效率高,弹性好,开发速度快,易调试。
互联网应用不要用SP,甚至直接访问表都不建议,要通过服务来实现,因为随着业务的扩充,可能要分库分表啥的。。。
----------------------------------------------
-我爱Delphi6
作者:
男 mousesoft (MouseSoft) ★☆☆☆☆ -
盒子活跃会员
2018/3/16 22:57:55
30楼: 确实不见意用存储过程,建议数据库只有留表、视图就好了,
----------------------------------------------
-
作者:
男 inbreak (入侵) ★☆☆☆☆ -
盒子活跃会员
2018/3/21 11:21:16
31楼: TO 30楼

如下是附件中的存储过程,请教如何在前台完成它。
此帖子包含附件:inbreak_2018321112116.zip 大小:6.8K
----------------------------------------------
我是菜鸟,己经搞了十多年了,但是我仍然很菜。
作者:
男 hawke2e (hawke2e) ★☆☆☆☆ -
普通会员
2018/3/21 12:17:13
32楼: 对待存储过程,一般态度就是有限度使用而且是有充分理由才用,主要因为它没有完整开发过程的支持,不方便纳入到开发管理中去。比如:要开发个结构很复杂的系统就不适用,设计和测试的支持都很不好。但一切从实际出发,比如:系统结构不复杂业务也不庞大,又有人员熟悉,何乐而不为呢
----------

楼主所提的困难不能局限在技术层面去看,社会发展的趋势都是社会分工越来越细。你之所以觉得困难是因为既要了解业务情况又得写代码,当然效率会很低。如果你只是专心写代码,比如:把结算过程写通用而不关心是美元还是人民币,把这些都交给外部去设置。效率自然会高很多。
之前的帖子我曾提及,为啥现在所谓的快速开发工具用处不大,是因为当你要做的业务不能复用工具时,你就得面对平台内部的技术架构,当你要重新设计界面时就得面对html、css等。这样不能从根本上实现快速;业务人员开发系统就得只处理业务,编程员开发系统就得只处理技术问题,这样才从根本上释放生产力。
----------------------------------------------
软件是什么,相信很多人都说不清。
作者:
男 zhuzh_yuy (华) ★☆☆☆☆ -
普通会员
2018/3/21 13:00:57
33楼: 根据实际情况适当用吧,存储过程有他存在的合理性,只能说尽量少用而已,不能一概而论地不用
----------------------------------------------
-
作者:
男 zhuzh_yuy (华) ★☆☆☆☆ -
普通会员
2018/3/21 13:03:26
34楼: 互联网企业的应用场景和使用的开发语言并不能完全代表所有行业,所以不能盲目追随
----------------------------------------------
-
作者:
男 wiseinfo (wisienfo) ★☆☆☆☆ -
普通会员
2018/3/21 20:28:01
35楼: 大牛都跟我这样说,
我用存储过程+触发器一直没毛病.
----------------------------------------------
-
信息
登陆以后才能回复
Copyright © 2CCC.Com 盒子论坛 v3.0.1 版权所有 页面执行104.4922毫秒 RSS