侃一下关于程序的“柔性”

〇〇

c语言真的不太流行了，谁看过我的人工计算cube源代码？

yulihua49

〇〇 发表于 2011-9-17 17:41
c语言真的不太流行了，谁看过我的人工计算cube源代码？

用红黑树的那个？

在性能、可靠性要求高的场合还是无法被替代。

我就不信你看不懂我那两行代码，是谦虚还是什么。
实际上，看懂注释就基本懂得了程序逻辑，有何看不懂？
可能个别语句理解问题，可以问，我解释。
大部分函数看名字，功能就差不多。只要知道函数干什么就行了，不需要知道怎么干。
当然真正要使用这个东西，要看一下文档。
在这里，我几句就解决了问题，你如果使用这个，也是几句就完成任务。经过简单的学习，你就可以极大的提高开发效率。

就这一段，从文件读数据，数组批量插入数据库：

1. //文件格式：   XXXXX|XXXXXXX|XXXXX|..............XXXXX|
   
2. for(rows=0;!ferror(ifd);) {
   
3.              fgets(buf,buflen,ifd);//读出一行
   
4.              if(feof(ifd)) break;
   
5.              OAD_pkg_dispack(&oad,n,buf,'|');//buf 数据装入数组。n是下标。初值0，‘|’分割符。
   
6.              if(BATCH_NUM == ++n) {//够数了
   
7.                      ret=insert_DAO(&oad,n,&_DAU,buf); //插入数据库，返回插入的行数
   
8.                      n=0;
   
9.                      if(ret<0) break;
   
10.                      rows += ret;
    
11.                      if(++commit_num == COMMIT_NUM) {
    
12.                            ___SQL_Transaction__(SQL_Connect,TRANCOMMIT);
    
13.                            commit_num=0;
    
14.                      }  
    
15.             }
    
16. }
    
17. //帖代码把前空都删了，请与老大反映一下。
    
18. 
    

复制代码

哪不懂，问。
看框架程序需要一个习惯，就是不问细节。
开始我看用HIBERNATE的程序，也是不懂。怎么？就这么两句，就完了？不懂。
后来发现，原来就这么两句，自己竟然不知道自己已经懂了。

里边涉及OAD和DAU的就两句，有注释，能懂吗？


你如何写一个从文件读数据，批量插入数据库？

newkid

"80or150列，确实是前端传过来的。通过之前的客户输入一部分，席位查询一部分，交易调整，票价计算，支付处理。。。。合成了这些数据，通过一个JSON包传过来的。"
真正来自售票员的那些（估计也就二十来个）才是事务的接口；至于席位查询一部分，交易调整，票价计算，支付处理......这些全部都由存储过程来完成。我绝不会让客户端染指这些计算，我要服务端具有百分之百的控制权。你可以声明一个 p_sell_row sell%ROWTYPE 参数，各模块只计算和自己有关的列，然后赋值。最后你这个p_sell_row经过所有模块的处理就合成了所有列的数据，只需 insert into sell values p_sell_row, 没有任何列名，够“柔”了吧？

至于你说的PRO*C的那些处理，我们PLSQL没那么麻烦，PLSQL的好处就是和SQL的无缝集成。
最后返回给客户的，我绝不会不加选择就返回150列，实际上够打印的数据就可以了。
至于那些打包拆包，在PLSQL中是不存在的，我们处理原始数据，实在需要就交给客户端去做。


"你如何写一个从文件读数据，批量插入数据库？"
怎么还没完？我说了“用合适的工具做合适的事情”，PLSQL强项不在文件处理字符串解析，我当然要扬长避短。用外部表满足了所有的需求，比你自己写的功能强一百倍。
更何况你这段代码还被我挑了不少毛病，虽然不是什么大问题。

yulihua49

newkid 发表于 2011-9-18 01:48
"80or150列，确实是前端传过来的。通过之前的客户输入一部分，席位查询一部分，交易调整，票价计算，支付处 ...

真正来自售票员的那些（估计也就二十来个）才是事务的接口；至于席位查询一部分，交易调整，票价计算，支付处理......这些全部都由存储过程来完成。我绝不会让客户端染指这些计算

服务器不可能处理这些问题。
每个都是单独的服务。席位查询，也叫席位申请，通过购票人交售票员处理申请并锁定一批票。
交易调整，有的票要，有的票不要，有的票调整成小孩票，这是一个交互的过程。不要的票还要调一个席位退回，以便别人使用。
票价计算根据交易调整的结果进行。根据最后的结果询问客人是否确认这笔交易。
客人同意支付，现金支付或通过pos或其他支付平台，记账时只记录支付结果。
支付，在当地进行，连接当地的支付平台，是人家的软件。服务器在北京，凭什么要北京处理你当地的业务?
最后，
每张票一记账，发的就是这个记账程序。记账成功后打印这张票。只有这个服务是一张票的操作，前边都是一批票的操作，含有大量人机交互，不可能一个服务完成。

好。我们老老实实来调存储过程，看点多少次列名：
形成自变量，一遍。有多少模块要调这个存储过程就有多少遍。
存储过程参数，一遍。
insert语句，二遍。
都要对准了，别错位哦。小心眼花。

然后再N遍的修改这些东西。

我们，如果是数据库表的模板，不用写。如果使用元数据，写一遍即可。许多模块都要用到啊，不是一个语句的问题，要生成许多语句的。

yulihua49

yulihua49 发表于 2011-9-17 18:38
用红黑树的那个？

在性能、可靠性要求高的场合还是无法被替代。

怎么还没完？我说了“用合适的工具做合适的事情”，PLSQL强项不在文件处理字符串解析，我当然要扬长避短。用外部表满足了所有的需求，比你自己写的功能强一百倍。
更何况你这段代码还被我挑了不少毛病，虽然不是什么大问题。---------------- 就一个毛病，我会改的。其余的在OO恢复的贴里解答了。


好了，这就是说批量处理这一块，我的是合适的工具。否则，在OLTP里极少使用批量处理，太繁琐了。
OAD是依赖DAU的，DAU是依赖模板的。系统里已经有了模板和DAU工具，程序员也学会了框架工具，还要不要用存储过程，什么时候用存储过程，是程序员自己的事。

一般认为包装的深度越深，使用越简单，但性能要差。
DAU是例外，它提供了高性能的手段，大大简化了你使用系统高性能机制的操作，所以能够帮助你非常简单的写出高性能程序。

174楼的那个程序，有不懂的吗？提出来，我解答，否则就是没人不懂了。（看过的都懂）。我要是写出来怎么弄的，恐怕没几个人懂。
所以看使用框架的程序，看做什么就可以了，不要看怎么做（怎么做是框架的事，不是你的事）。前边的程序看不懂，问题就在这里，看不到SQL，心里完全没底。只要框架文档看明白了，写业务逻辑很简单的。

newkid

你的大量人机交互结果，不必要全部都回传吧？比如选中的席位，最终只需回传那个席位的ID。总之我认为客户端只需传入完成事务的最少数据，全部150都在客户端生成是很不靠谱的。
支付系统如果通过第三方完成，你当然只能传入结果了。从设计上这些数据不应该存在销售表，必须分为另外的支付表，销售表只管通过某方式收回了多少钱，不需记录其他细节。

“我们，如果是数据库表的模板，不用写。如果使用元数据，写一遍即可。许多模块都要用到啊，不是一个语句的问题，要生成许多语句的。”
如果你的150列模版被许多模块用到，说明它们都在用SELECT *, 都不是只访问自己所需的数据列，这是一种浪费。


“好了，这就是说批量处理这一块，我的是合适的工具。否则，在OLTP里极少使用批量处理，太繁琐了。”
批量处理当然是极少使用了，你们难道整天在加载数据？
合适的工具是：你只需把文件上传到数据库的某个目录，剩下的交给存储过程完成，又快又好，没你什么事儿。

nannan5000

174楼的 代码 写的 还比较清晰

能写出174楼的代码 还得yulihua49  这样的高手 在架构的角度设计

目前很多的小公司 都是用什么ssh 啥的之类的框架。

很多架构性的东西都不是由自己完成的，这种的框架限制了 存储过程的使用。

yulihua49

newkid 发表于 2011-9-19 22:54
你的大量人机交互结果，不必要全部都回传吧？比如选中的席位，最终只需回传那个席位的ID。总之我认为客户端 ...

批量处理当然是极少使用了，你们难道整天在加载数据？

我那个代码主要用于调试OAD。在实际的OLTP应用中，批量插入可以显著改善性能。
如列车编组顺序表，从MQ来，分为报头和正文。报头是关于列车的信息，正文是每辆车的信息，有几十到200个记录。如果一个批量插入，效果显著。其它如股道和车辆，车次和停靠站，订单和一批票等等。我的程序可以做一个DEMO，照猫画虎就可以了。

当然，原来那些程序也改不了了，我只说一个可能性。最近一个朋友，要做一个从车号识别系统，收列车编组信息，与确报核对的工作，我教他用OAD，很好用。之前我问，循环插入好呢，还是成组插入好。他说当然是成组好。
程序是很成功的，不过项目进展怎样，我不知道。

如果从客户端`（传感器）传过来一个数组呢？你怎么玩？可以循环调存储过程（还不如循环调插入语句）。但肯定没我快。

我同意你的观点，用合适的工具作合适的事。
就柔性程序而言，框架是更合适的工具。存储过程不是不可以，干起来很别扭。

关键是效率，与可靠性如何，人们不会轻易相信你。
DAU是这方面的一个尝试。

yulihua49

newkid 发表于 2011-9-19 22:54
你的大量人机交互结果，不必要全部都回传吧？比如选中的席位，最终只需回传那个席位的ID。总之我认为客户端 ...

如果你的150列模版被许多模块用到，说明它们都在用SELECT *, 都不是只访问自己所需的数据列，这是一种浪费。

可以子模板，也可以except_col.


你的大量人机交互结果，不必要全部都回传吧？比如选中的席位，最终只需回传那个席位的ID。总之我认为客户端只需传入完成事务的最少数据，全部150都在客户端生成是很不靠谱的。
支付系统如果通过第三方完成，你当然只能传入结果了。从设计上这些数据不应该存在销售表，必须分为另外的支付表，销售表只管通过某方式收回了多少钱，不需记录其他细节。

这不关我事，他们怎样设计都行。更可恶的是，设计了许多表，电子订单细目，支付记录，甚至退票存根和废票存根，大批列内容相同。我不赞同，没用。
有同列同名的规则，所以为他们设计了DAU_copy();其他人感觉不把牢，可以不用。人家一个json就过来了，如果存储过程，老老实实，N多列传进去。
人家数据结构怎么设计，业务逻辑怎么设计，我们搞架构的管不了，只提供支持。

yulihua49

nannan5000 发表于 2011-9-20 07:52
174楼的 代码 写的 还比较清晰

能写出174楼的代码 还得yulihua49  这样的高手 在架构的角度设计

还好，我的框架支持存储过程。甚至可以在客户端直接调存储过程，带参考游标的。这可就是有状态服务了，TUXEDO立马傻眼。
服务器有专门的存储过程转发服务，交易管理器有专门的状态保持机制，在参考游标关闭前，持有你的连接。