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

yulihua49

newkid 发表于 2025-9-16 22:06
谁说"没有其他办法可以代替"? 我不是说了用配置表就可以吗？现在算法完全不可人工校验，而且它也只是猜测， ...

鲁布格得我不懂，就知道是当时的老总姓战，战总提出来的，由同济大学搞得算法，同济大学依据上海地铁的情况弄的，跟北京很不适应。不过这些我们管不着。至于你说的代替方法，我不懂，估计他们也不懂。目前就是这个软件在运行，客流统计的就是这个数据，清分用没用我不知道。离职9年了，头一两年还有联系，后来就没消息了。

yulihua49

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

insert，update也用。后来不是发了choose some columns的例子吗？
批量处理主要在OLAP用，OLTP用的少。
不过以前弄过一个项目，应该用批量处理的，当时不会。模板用了，柔性也用了。
就是铁路编组站管理，有一个列车预确报收发功能。确报是从MQ传过来（最早是人工电报所），收入数据库。
经过站调处理，变成轨道列车编组。进进出出变来变去的，都是批处理。
一个报头，几十辆车的信息，就是几十条记录，可以一笔入库，转移的，当时是一条条的插入。
这是个OLTP系统。
列车接车，解体，重新编组，出发等等，软件上就是数据编辑，都是几十个记录成批处理。

yulihua49

newkid 发表于 2011-11-2 23:39
"存储过程不支持使用模板"谁说的？我事先把所有SQL生成好保存到表里怎么不行？你不也是这样做？这个不叫“ ...

可以呀，你也可以研究你的柔性编程的方法。就是在数据结构变化的时候，程序尽量少变化。
我只能为C语言搞柔性，因为C语言干这个其实很难。因为没有反射功能。JAVA有反射功能，搞这方面的框架挺多。
我就是搞了一个模板功能，来替代反射，使得C语言的柔性编程得以实现。当数据结构改变时，修模板即可。
当实现柔性的时候，有一种声音，说开销代价太大，得不偿失。
我就拿出了搞过的一个项目，说明我这个柔性编程，效率非常高，把一个需要11个小时的工作，弄成150秒。如果不搞批量update，批量insert，这150秒光入库时间都不够，别提计算了。如果不搞模板，批量操作烦死人，150个列，你愿意一个列一个列的去写sql，一个一个列的去写：占位符，一个一个列的去绑定变量吗？199楼的表，类似的有6个，谁愿意手搓这些操作？

newkid

上面说过了，这个所谓“11个小时的工作”，包括后面的“批量update，批量insert”全部都是因为不当需求人为制造出来的，这是为了解决问题制造问题。
退一步说，我们PL/SQL里面几乎是用不着占位符，手工绑定变量的，这个语言天然就和SQL无缝结合，PLSQL变量自动绑定，能“最大”发挥SQL的优势。

yulihua49

newkid 发表于 2025-9-17 22:55
上面说过了，这个所谓“11个小时的工作”，包括后面的“批量update，批量insert”全部都是因为不当需求人为 ...

这个是用户需求，合理不合理，我们无权讨论，对于我来说，要么干，要么不干。
要干的话就只能这么干。原有的算法就是C++写的，我有什么资格要求人家改存储过程呢？算法不是我写的，我也无权过问，我的任务就是调度资源确保任务在规定时限内完成。
原来的算法，全部使用内存数据，我还要负责把基础数据从数据库提取到内存，并保持版本的一致性，构建成它所需要的组织形式，哈希表，排序数组，二叉树等等。一共需要大概6个大的数据结构。这些数据结构也是会经常改变的，所以同样是需要柔性编程技术。
那公司里，ORACLE高手也不少，存储过程也玩的溜溜的，没有解决问题呀！
你的问题，难道数据库的功能只有存取吗？在这个项目里确实，但是在公司大的业务范围，存储过程用的很多，他们ORACLE的人才也不少。
地铁是甲方，公司是乙方，这个项目乙方有权说你的需求不当吗？有权说，因为存储过程干不动，所以你的需求不当？干不了你别干，有的是人干，就这么简单。

yulihua49

newkid 发表于 2025-9-17 22:55
上面说过了，这个所谓“11个小时的工作”，包括后面的“批量update，批量insert”全部都是因为不当需求人为 ...

11小时工作与柔性编程是两个概念。
11小时工作与数据库无关，就是计算量，纯CPU，1天400万个数据（现在1000万了），夜间2点日结，算不完。说明计算很复杂，存储过程玩不转。必须是编程语言来处理。公司平台是C++。sparc+solaris。这个项目用linux+intelCPU的服务器。
算法与数据库整合以后，就要解决数据访问效率问题，从复杂的算法又加上一块数据库访问。
解决方案主要是并行处理，利用尽可能的核进行均衡的任务分派，于是，从文件或数据库取得数据，分批，均衡的分配给多台服务器的多个线程进行并行处理的架构就形成了。处理结果要存入数据库，这个是个IO过程，如何使IO不拖累计算也是考虑的重点，批量insert和批量update就是较好的解决方案。数据比较大，见199楼。这时候，语句生成，列名和占位符，绑定变量，解析结果集。还有在任务分配中需要的序列化反序列化等等，就成了繁琐而易错的工作，而且，数据结构是会变的，算法也会变。这种情况，就是柔性编程jiao好的应用场景。

以上就是个例子，如果还有计算量数据存储量都很大的项目，也适用。

newkid

告诉你一个入口站，一个出口站，正常人几秒内就能想出该怎么坐车了；不常用的线路，就查查表也很快知道怎么坐了。这就是我说的用配置表做连接的方法。你们用户偏要搞成“计算很复杂，存储过程玩不转”的局面，还有什么好说的？要干蠢事谁能拦得住？你说你们公司是乙方，这可有点意外，不过国企经常弄一大堆子公司，把钱从左口袋搬到右口袋，也不是什么稀罕事。

yulihua49

newkid 发表于 2025-9-23 08:18
告诉你一个入口站，一个出口站，正常人几秒内就能想出该怎么坐车了；不常用的线路，就查查表也很快知道怎么 ...

不知道坐哪个车次呀，也不知道什么时段进入那个区段，怎么进行车次区段客流统计。
而且有2号线10号线两个环线，可行方案多了去了。

yulihua49

newkid 发表于 2025-9-23 08:18
告诉你一个入口站，一个出口站，正常人几秒内就能想出该怎么坐车了；不常用的线路，就查查表也很快知道怎么 ...

查查表就是那个可行路径表，原来就有啊，从地铁开通就是这么用的。后来各条线路承包运营，各家不干呀，要求具体化的统计数据。所以才搞了这么一个算法，依据时间和车次，估计实际走行路径。
另外，本帖的目的是讨论在C语言的数据库应用中，柔性编程的意义。
现在直接使用C语言处理业务的是越来越少了，不是高计算量大吞吐量的系统，都不用C了。这是一个使用C的比较典型的例子。
如果有高计算量大吞吐量的系统，可以参考一下。
如果今后要使用AI系统处理业务，更是需要这种架构，从数据库取出数据，经过AI处理，结果存入数据库。
除非你的存储过程直接挂AI，ORACLE有能力这么做。但是这样的售价就天文数字了。

还有，大量OLTP业务都是从数据库取出数据经过前台人工处理，结果存回数据库，都可以用到柔性编程，用于适应数据结构的变化。
其实柔性也不复杂，简单说，就是不对列进行点名枚举处理，或尽量少点名，必须点名时集中在一个地方（就一处），保证所有相关模块进行一致性处理。
本帖讨论半天，还想说明一个问题，柔性编程效率很高，不存在开销过大的问题。

yulihua49

newkid 发表于 2025-9-23 08:18
告诉你一个入口站，一个出口站，正常人几秒内就能想出该怎么坐车了；不常用的线路，就查查表也很快知道怎么 ...

2.2        业务功能分析
路径匹配算法模块接收从任务管理分配器模块发送的出站交易数据，同时从数据库中读取路网基础参数、带比例的有效路径集数据以及当前可用的运行图数据,根据这些信息对每一条UD数据进行处理。
首先根据清分规则，对UD数据属性进行判断，如果是正常的UD数据，则通过推定型算法匹配出最可能的乘车路线、对应的车次、上下车时间以及各线路票款等结果数据，如果是特殊UD或异常UD，则通过分配型算法结合有效路径比例获取乘车路径，然后根据顺推法获取同样形式的结果数据。将这些结果数据，更新到数据库原始的UD数据表中。


你说的就是分配型算法，推不出来时用。