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

newkid

我的观点还是和十几年前一样，不用写代码，外部表加一个merge 搞定！另外你竟然还用rule hint 这个也太搞了吧？

yulihua49

newkid 发表于 2025-9-14 20:51
我的观点还是和十几年前一样，不用写代码，外部表加一个merge 搞定！另外你竟然还用rule hint 这个也太搞了 ...

不懂。数据在内存，是从管理器收来，是一个结构数组，经过复杂计算，把这个数组update回数据库。怎么merge？
每个记录都有主键，按主键对位进行update。需要强制使用索引。

yulihua49

newkid 发表于 2025-9-14 20:51
我的观点还是和十几年前一样，不用写代码，外部表加一个merge 搞定！另外你竟然还用rule hint 这个也太搞了 ...

一个结构数组，怎么变成外部表?（序列化，写文件，把文件搞成外部表，merge，删除外部表，删除文件，好几十个线程同时搞事。有这时间，我的一大堆线程OAD_exec()早搞完了）
这个系统最开始设计时，考虑过外部表方案，做了试验，非常慢。故否之。
当时好几派观点，都试验过，最后我的方案胜出。管理器从数据库读出数据，分成每包1000行，提交给3台服务器，每个服务器32线程，同时处理，文件名和外部表名都不好搞。96个外部表同时往一个表merge？
2台数据库服务器rac。16线程并行效率最高。管理器1个连接负责读出数据。每个服务器5个连接共16个。32个线程抢5个连接，得到连接的慢慢腾腾玩merge，别的线程等不起。

newkid

我还以为你的源数据放在文件里呢？现在才看到“管理器从数据库读出数据”，数据已经在库里面，再写外部表不是有病吗？直接就MERGE, 里面的USING子句功能强大，不是纯粹的读表，可以连接，聚合，可以用分析函数，上天入地无所不能。你的模板能支持表达式吗？能支持表连接，聚合吗？只能行对行，列对列修改吧！MERGE也可以支持并行。

udfrog

newkid 发表于 2025-9-15 08:51
我还以为你的源数据放在文件里呢？现在才看到“管理器从数据库读出数据”，数据已经在库里面，再写外部表不 ...

让我想起我工作第二年还是第三年在ibm的时候，刚接触db2不久，数据库0经验，然后为了优化我们一个etl job，跟band8的老外建议，把表做成年表，来减少io，然后老外说这就是数据库里分区表的作用。。。老yu技术扎实，但是对于数据库。。。四个字吧，一窍不通。

yulihua49

newkid 发表于 2025-9-15 08:51
我还以为你的源数据放在文件里呢？现在才看到“管理器从数据库读出数据”，数据已经在库里面，再写外部表不 ...

不是。需要的数据是百万级规模，需要进行复杂计算，由管理器读出，分包，分发给多台服务器的多个线程去计算，计算结果是结构数组。然后把计算结果update到原来的行。计算是非常的复杂，计算量也很大，所以用C++编程，每1000行记录打包分发给3台服务器，共96个线程进行计算，现在咱们从计算结果入库这个环节开始，就是198楼的程序。

如果用merge，看198楼的update_DAO（）；我打算这么办:
先用PI_EXIT_RESULT常数串建立CUT_PI_EXIT表的子模板，
生成临时文件名，同时也是外部表名。为了区分不同的服务器，名字需带上服务器ID。
打开临时文件；
用子模板序列化数据写入文件。
关闭临时文件。
以上不需要数据库介入，以为32个线程进行计算，只有5个数据库连接。尽量少占数据库资源。

取数据库连接。
用子模板建立CUT_PI_EXIT表的DAU。
DAU_exec("建立外部表”）；
用DAU生成merge语句；
DAU_exec（merge语句）；
DAU_exec（删除外部表）；
析构DAU；
归还数据库连接；
删除临时文件。

这个流程依然是柔性的。就是说，当数据库表修改，只要重新生成模板和PI_EXIT_RESULT，重新编译即可。程序本身不需要修改。
是不是比198楼的操作复杂多了？就处理临时文件的功夫，OAD_exec早就完事了。
你用存储过程，这时候必须修改merge语句，是不是不够柔？我只是举了个例子，在实际系统中这种情况比比皆是。
另外，merge我确实不懂，是否可以处理按主键进行update部分列。是否在RAC环境支撑多个外部表同时merge一个表？请解惑。

写完了。

yulihua49

udfrog 发表于 2025-9-15 17:18
让我想起我工作第二年还是第三年在ibm的时候，刚接触db2不久，数据库0经验，然后为了优化我们一个etl job， ...

谢谢你的批评。我在努力学习，所以跟这里的大佬进行沟通。也请你看看206楼，提点意见。
另外，我的数据库包装器有DB2的，是2010年在与IBM协作中开发的。用的CLI和ORACLE兼容模式。开发完测试也挺有意思，两个人写同一个插入数据的测试程序，我的包装器比他快40多倍。我没跟老板说，他用的是插入值，我用的是绑定变量。

后来，一个项目，原来是基于ORACLE的。突然业主提出改DB2。
开发一半的系统，换数据库。。。。。。。。
这个系统有好几个小组，一个是C++的，一个是数据库的，还有其它的。
C++这个组使用的就是我这个包装器，恰好在IBM弄的DB2包装器派上了用场，所谓包装器，就是不管底层用什么数据库，应用函数是一样的，所以应用程序基本不需要改，这也是柔性编程的一个方面。
2天功夫移植完成，之后一个星期就是协助数据库组调整存储过程。因为那些存储过程都是通过前面的C++程序调用的。一个负责数据传输的哥们，原来没用我的数据库包装器，自己用ORACLE的OCI，反正也是高手。换DB2的时候，搞了一下CLI，搞不定，后来还是找我要去了DB2的包装器才改成功。
看我前边的程序了吧，使用数据库不写SQL语句，让程序生成SQL语句，不仅是省事，不易错，更重要的是，可以更换数据库，每种数据库，SQL语句是略有差异的，这个差异在语句生成器里被调整过来了。
最有意思的是SYBASE的语句生成器，要想把他数据库里的日期类型变量翻译成ORACLE格式老复杂了。遗憾的是，MYSQL包装器的批处理没搞出来，最近跟AI学习了一下，可以搞，可惜，退休了，手边没有开发环境。
批量处理，ORACLE用的是OAD，DB2直接用DAU。有这么一点差异，移植时需要改。
DB2的那个系统投产了，用的挺好，就是有一个奇怪的问题，服务器连续运行3个多月就会崩溃。检查没有内存泄露。估计是内存碎片化，内存分配失败就会崩溃。似乎没有ORACLE稳定。

yulihua49

newkid 发表于 2025-9-15 08:51
我还以为你的源数据放在文件里呢？现在才看到“管理器从数据库读出数据”，数据已经在库里面，再写外部表不 ...

看198楼程序，你老是忽略“经过计算”这几个字。计算太复杂了，你那个“无所不能”恐怕搞不定。

newkid

有多复杂？用上GPU了吗？很多时候人们都把数据库当作存储设备，不知道它还是计算设备。所谓“搞不定”往往是因为对SQL语言还不了解。更何况ORACLE还支持C存储过程，JAVA存储过程。总之我的思路是不让数据离开数据库，既然没有了“拿出去”这个步骤，就没有必要讨论怎么“写进去”了。

newkid

yulihua49 发表于 2025-9-15 20:53
看198楼程序，你老是忽略“经过计算”这几个字。计算太复杂了，你那个“无所不能”恐怕搞不定。

我的回忆在慢慢苏醒，你说的这个“复杂计算”，莫非就是你津津乐道的那个清算程序？就是根据一张票的出入口，时间来推测他的行走路线，然后营运商按比例分钱。当年我一针见血看出这是个伪需求，无非就是巧立名目骗经费，生意人哪有可能按你读书人的规矩来分钱！时隔多年以后，你不情愿地承认，这个程序确实从未投入生产，白花花的银子做出来一堆参考数字，就是看着玩玩而已。抛开这些，要实现这个需求也有好得多的方法，只要事先把所有出入口组合的分摊比例计算好，最多再加上时间参数，一起放到配置表中，一个JOIN搞定！哪里还需要一本正经地“计算”。