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

〇〇

任何情况下，开发人员必须听领导的。

yulihua49

原帖由 〇〇 于 2011-8-27 11:16 发表
任何情况下，开发人员必须听领导的。

对。有时可以说服或引导领导。

newkid

原帖由 yulihua49 于 2011-8-27 10:22 发表

这不是我自己的习惯思路，而是模块化软件的一般形态。拿到手一批数据，分别由不同模块完成不同功能。框架必须支持模块化编程。不同的模块有的在本程序里，有的发还客户端，有的另外调用其它功能引擎（服务器）。。。。你不能限制用户对数据的用法。我是举一个例子，你不要老是具体看这个例子，把它抽象成一个模型来看。（票价计算模块用在很多场合，有的应用根本就没有数据库，你怎么让他使用PL/SQL？，这也是代码重用的例子）经常算法是另外一帮人搞的，你必须为它提供数据，你无法要求人家必须用PL/SQL写，甚至不能要求用C写。我们现在就有C，C++，JAVA混合的应用，要么为什么用JSON传来传去的呢？数据库映像成结构，结构再映像成别的数据格式。。。

现在引申出一个问题，即便一些算法用存储过程实现，你还是要把结果传出来，如果结果非常复杂，在C里如果接收这个结果还是个麻烦。（你倒是没几句话就完了，我得多少代码来鼓捣这点数据啊）。

我认为你倒是有习惯性思路，PL/SQL包打天下。它可能能够干不少事，但未必都是强项。
我的思路是天下大家打，我来提供整合。

大规模系统的任务是需要分担的，有许多服务器各自干不同的任务。数据库服务器就负责数据持久化处理。计算的工作交给计算服务器。
一般的单位，数据库服务器都是小型机，HP，IBM什么的，计算能力明显不行（如果计算能力强，ORACLE还得多收费）。中间服务器是高主频多CPU的X86－64系统，（便宜，可以设置庞大的阵列系统）具有强大的计算能力。客户端成百上千，分布式计算何不让客户端来做呢？

我们之间，如果一台服务器，比不出所以然。要是两台小型机，10台微机刀片服务器，数百台客户端的系统，看看哪个方案事务吞吐量高。客户最终还是看花多少钱，得多少处理能力。
所以不要妄自批评人家的架构，人家有人家的道理。我们的任务是支持客户需求。

语言不同就无法代码重用；计算逻辑必须集中，否则即使都是C程序，版本维护也够你喝一壶的！简单的逻辑可以分别实现，能集中的还是尽量集中。
存储过程传递结果可以用游标，可以用嵌套表（对象数组），我们都是这么干的，从来没有问题。你不要老想着鼓捣数据，客户端只需显示就行。
"如果计算能力强，ORACLE还得多收费"这个什么意思？
再复杂的业务规则，无非也就是加减乘除，这些所谓“计算”对oracle根本构不成额外负担，可以说是顺便的。

newkid

原帖由 〇〇 于 2011-8-27 08:51 发表

我们有2个应用，干一样的自定义汇总表事，第一个全用界面拖出来+一些自己发明的表达式，第2个整个用SQL写出来，结果用户领导说，第1个好。。。第2个要修改

领导就喜欢花花绿绿的东西。两个的性能差距可能是几小时和几分钟的差别！

yulihua49

原帖由 newkid 于 2011-8-28 08:17 发表

存储过程传递结果可以用游标，可以用嵌套表（对象数组），我们都是这么干的，从来没有问题。你不要老想着鼓捣数据，客户端只需显示就行。
。

不鼓捣不行。得把结果集送客户端。客户端是不能连数据库的，必须通过中间件。
所以必须鼓捣出来，送走。所以必须用包装器，帮助鼓捣数据。
包装器使SQL命令和结果集容易在网络传输。

不是所有的应用逻辑都那么简单，不能用我们自己的想法代替客户。就有很复杂的运算，数据库提供或存储数据，人家自己运算或通过第三方的计算引擎进行计算，如GIS等等。

我们现在是松耦合的方法，所有功能都是分离的，由各自的部件分别处理。

[ 本帖最后由 yulihua49 于 2011-8-30 15:43 编辑 ]

newkid

不管是何种开发语言都能够从存储过程获得游标，这个游标的访问非常简单，如果仅在这一层进行包装花不了多少代码（而不是你现在做的试图生成SQL那些事情）。所以把SQL交给存储过程去做，大家都省事。
我不否认有复杂计算的应用，但是OLTP不是GIS, 它处理的就是交易数据而已，这种应用就适合用存储过程。
分离没有问题，即使在存储过程中也可以分层次、模块化，我反对的是不必要的“分散”。

nannan5000

搞不懂 为什么 现在NoSql流行

留下几个链接 供大家了解

SQL数据库的终结

http://www.aqee.net/the-end-of-sql-and-relational-databases/
http://www.aqee.net/the-end-of-sql-and-relational-databases-2/
http://www.aqee.net/the-end-of-sql-and-relational-databases-3/

yulihua49

原帖由 newkid 于 2011-8-30 22:30 发表
不管是何种开发语言都能够从存储过程获得游标，这个游标的访问非常简单，如果仅在这一层进行包装花不了多少代码（而不是你现在做的试图生成SQL那些事情）。所以把SQL交给存储过程去做，大家都省事。
我不否认有复杂计算的应用，但是OLTP不是GIS, 它处理的就是交易数据而已，这种应用就适合用存储过程。
分离没有问题，即使在存储过程中也可以分层次、模块化，我反对的是不必要的“分散”。

我们要支持：不仅分散，而且分布。至于分散到何种程度，由用户决定。我们支持他们，把任务分散到网络的各个节点。他们之间需要进行数据传输。
数据打包就是利于传输。DAU-SDBC系统就是一个打包-传输系统。当然，可以打包成存储过程，那有点罗嗦，打包成SQL语句更简洁些。
实际上，我们之间没有太大分歧，不过你是要求直接写SQL，但是直接写SQL我就没法打包了。反正都是SQL，没啥区别。
结果是，发现即使数据不传输，直接用打包程序写业务逻辑，也挺方便的。不用太费劲，程序还具有了相当的柔性。你虽然也写了个柔性的程序，可是可读性呢？
就程序的可读性来说：

1. 
   
2.       CASE
   
3.       WHEN lv_col.DATA_TYPE ='DATE' THEN
   
4.            lv_sql := lv_sql||   '||''"'||lv_col.column_name||'":"''||TO_CHAR('||lv_col.column_name||','''||lv_date_format||''')||''"''';
   
5.       WHEN lv_col.DATA_TYPE LIKE '%TIMESTAMP%' THEN
   
6.            lv_sql := lv_sql||   '||''"'||lv_col.column_name||'":"''||TO_CHAR('||lv_col.column_name||','''||lv_time_format||''')||''"''';
   
7.       ELSE
   
8.            lv_sql := lv_sql||   '||''"'||lv_col.column_name||'":"''||'||lv_col.column_name||'||''"''';
   
9.       END CASE;
   
10. 
    

复制代码

-----干嘛呢？一堆标点符号的集合。比写列名看着还累，更晕。
我这里：
                DAU_toJSON(&table_DAU,json,0);
一看就明白，数据转换成JSON格式。读者甚至不需要知道JSON的具体内容。里边可能也有类似的代码，封装了，看不见，但你可以无数次使用这个代码。

正在做的，就是从OLTP系统，取出节点参数，送给GIS系统，进行地理显示。乘客可以在地图上点击节点，OLTP服务器提供参数和结果。或者反之。
更广义的讲，你无法预设系统功能。当初做售票系统，没想到用GIS。

不能断言，应用逻辑就是就是加减乘除的集合。例如：你也可能用PL/SQL写出个通用的JSON处理包。那性能可能就杯具了。
所以这点活还是交给别人干。你要是不写成JSON格式呢？我就杯具了，没有模板，我怎么解释你的结果集？有了模板，用你这程序干啥？问题已经解决了。

[ 本帖最后由 yulihua49 于 2011-8-31 11:41 编辑 ]

yulihua49

原帖由 newkid 于 2011-8-28 08:17 发表

如果计算能力强，ORACLE还得多收费"这个什么意思？

ORACLE是按系统性能收费的。
ORACLE应该高薪聘请你做售前服务。你会说服客户采用你的解决方案。这样所有的压力都集中在数据库引擎上。必须购买强力的服务器。
ORACLE可以多挣钱，小型机厂商也可以多挣钱。还可以防止客户甩掉ORACLE投奔别人。

我们那帮ORACLE的售前，问他们，是否存储过程性能更好，都是支支吾吾的。

yulihua49

原帖由 nannan5000 于 2011-8-31 08:35 发表
搞不懂 为什么 现在NoSql流行

留下几个链接 供大家了解

SQL数据库的终结

http://www.aqee.net/the-end-of-sql-and-relational-databases/
http://www.aqee.net/the-end-of-sql-and-relational-databases-2/
http://www.aqee.net/the-end-of-sql-and-relational-databases-3/

数年以后，我估计我们大多数还是要依赖于关系数据库和SQL。我当然有愿望，我将会不断的研究寻找更好的方式去弱化和封装数据访问操作。一直以来， 任何工程决策都是跟用户和业务需求相适应的。对于以后的软件工程来说，我相信，
我们一定会找到一个合适的非关系型数据存储产品。你是否正在使用非关系型数据库呢？你是否已经放弃了SQL和关系型数据库呢？你是否正在把你的数据转移到 一个公共的或私有的云数据库里呢？请发表评论。

我认为，各有各的优势，谁也不会终结。将来我们的应用会混合各种数据持久化方案。他们可能在一个或多个网络节点协作，我们的柔性编程也包含这个意思。
在网上，可以传送各种数据，不同的源和目，通过DAU-SDBC系统可以容易的将它们整合在一起。（当然，别的系统也行，我们交流嘛）

文中提到，随着ORM兴起，SQL越来越像noSQL,DAU也是。DAU就是SRM，Struct Relational Mapping。
里边提及JSON检索库，XML检索库。ORACLE的XML检索已经实现。我们前边的例子，尝试了json检索功能。
json的删、改、插我们也实现了。性能可能没有专门的json库好，但容易实现二者的互操作。


另外，我懒得写SQL的列名，同样懒得写JSON的对象名（还有那些标点符号）。
DAU_insert(),DAU_select(),DAU_toJSON(),DAU_fromJSON(),多好，啥名也不写。（客户端写了，我为啥还要重复写？）
因此，noSQL可能也是要包装的，作用之一也是不写对象名。作用之二是各种数据的操作差不多，少学习些方法。作用之三是方便的在各种格式间转换。
各种格式的映像，关系是最难的。至今没见到在C下映射R的好方法。DAU做了这个尝试，证明其可行性及效率（JAVA的FANS常常藐视C，说访问数据库太困难。这里我可以回答，DAU访问数据库，比hibernate还要方便、可靠、高效。hibernate要想处理一个未指明结构的数据也是比较困难的）。希望起到抛砖引玉的作用，期待更好的方法出现。

[ 本帖最后由 yulihua49 于 2011-8-31 13:42 编辑 ]