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

yulihua49

原帖由 newkid 于 2011-8-25 21:57 发表


敢不敢让PLSQL参加？

当年我不在，是BEA、ORACLE、HP三家厂商举办的，还是在日本，用一个大环境做的。测试代码看了，TUXEDO+PROC写的。

3833020

原帖由 yulihua49 于 2011-8-26 11:04 发表


这完全是两码事。架构不是我定的，客户，不管是否使用DAU，或SDBC，都是那个架构，我不能干涉。（具体见71楼）
编译部署需要花点功夫也是服务器端的事。

我们再讨论一下我俩程序的事。
诚然，你基本实现了题目要求，而且代码较短。
但是，你的代码含金量太高。非你等超级高手玩不转。试想，如果再有N多类似题目，别人来做，他一定要认真学习你的程序。那里有太多的知识点。
我的代码，都是简单语句的堆砌，任何一个粗通C和SQL的低手都能轻易看懂。（只是分页语句有点困难）。
当然，这里的形势是一边倒的，因为，能参加这个讨论的，都是武林高手。高手是不需要什么工具的。是否考虑过，如何能让低手也能轻易写出高质量程序的

试想，你的公司，能够雇一群大侠？不仅代价太高，还有一山能容几只虎的问题。大量生产的商业软件，只能使用普通劳力。
包装的作用之一，是隐藏概念。用者使用你的工具，无需了解工具的内部构造和原理。
比如，解析一个表结构，只需：DAU_init(&dau,SQL_Connect,表名，0，0）；怎么分析的，不需要知道。再写别的程序，也是这么用。这就是程序的可重用。
你的呢？，必须认真跟你学，要了解该过程的细节原理，再写自己的程序。换个数据库，DB2怎么来？再学。

我们呢？客户的程序，基本不用变的，保护了客户的智力资产。

其实plsql不难学，只是很多开发者不愿意学了解它而已。

很敬佩yulihua49写出来的模版，大大减少了开发者的重复劳动
这样的工具的确是很好 -- 特别对于降低开发的周期和成本来说

但您说的 “换个数据库，DB2怎么来？再学。”，这里很有疑问
本身不同的数据库的实现方式就是不同的
比如说sql语句
db2就号称有着最好的sql解释器，而oracle在一个语句非常复杂的情况下，可能得到的执行路径就不是最优的，需要转为plsql块来实现
又比如说锁
这个可是会影响到事物的处理逻辑的
又比如说绑定变量，在不同数据库中的处理也有差别
要用一个通用的包处理这些不同，那么就要求写这个通用包的人对这些数据库都非常了解！
oracle大师Tom也说了，找一个精通oracle，mssql，db2这三种数据库的人和找三个分别精通不同库的人好像要难的多吧
这就如java和c，都可以开发出应用，但是同时精通这两种语言的人肯定比只精通一门的人要少的多
也就是说面对不同数据库之间的不同，总要有一个环节去处理
区别是是写通用模版的人需要精通不同数据库的差异去处理
还是不用模版直接由写应用的人去分别对不同的库写出相应的代码
当然，如果楼主真的精通不同数据库的话，把这种数据库之间的不同向开发人员隐藏了，那么我想会有更多的人支持它的
系统中如果大量的数据库交互都是较简单的sql，使用楼主的方法没有什么不好，提高了效率。
特别是面对客户不停修改的增加列的需求的时候。
如果系统中数据处理比较复杂的话，还是用plsql吧，它更适合，大表的多表hash，比起循环，那不是快了一点。

当然newkid的观点是数据库就是工具，不同的数据库是不同的工具，
就像刀，有菜刀，砍刀，指甲刀，虽然都有刃，但如果使用者不知道自己手里拿的是什么刀的话，可能吃亏的就会是自己。

看了楼主和newkid两位大师的精彩讨论，很受益匪浅，也就来发了两句牢骚

yulihua49

原帖由 newkid 于 2011-8-25 21:53 发表
我对你的传变量方式不满意，比如WHERE ID>=:P_ID1 AND ID<=:P_ID2 后面的VALUES怎么传？我如果来设计接口就不这么传，我会用变量名而不是列名，因此里面也用不到REGEXP_REPLACE, 用REPLACE就行。
你的模版无非就是自己又定义一套字典。如果我对某个日期格式有特殊要求我可以创建一个视图。

values:{"P_ID1":"值","P_ID2":"值"}

视图能解决日期格式问题？
不同列有不同格式。
开车日期：YYYY-MM-DD
作业时间：YYYY-MM-DD HH24:MI:SS
时间戳：YYYY-MM-DD HH24：MI：SS.FF6
进站时间：YYYY-MM-DD HH24:MI

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

yulihua49

原帖由 3833020 于 2011-8-26 12:56 发表


其实plsql不难学，只是很多开发者不愿意学了解它而已。

很敬佩yulihua49写出来的模版，大大减少了开发者的重复劳动
这样的工具的确是很好 -- 特别对于降低开发的周期和成本来说

但您说的 “换个数据库，DB2怎么来？再学。”，这里很有疑问
本身不同的数据库的实现方式就是不同的
比如说sql语句
db2就号称有着最好的sql解释器，而oracle在一个语句非常复杂的情况下，可能得到的执行路径就不是最优的，需要转为plsql块来实现
又比如说锁
这个可是会影响到事物的处理逻辑的
又比如说绑定变量，在不同数据库中的处理也有差别
要用一个通用的包处理这些不同，那么就要求写这个通用包的人对这些数据库都非常了解！
oracle大师Tom也说了，找一个精通oracle，mssql，db2这三种数据库的人和找三个分别精通不同库的人好像要难的多吧
这就如java和c，都可以开发出应用，但是同时精通这两种语言的人肯定比只精通一门的人要少的多
也就是说面对不同数据库之间的不同，总要有一个环节去处理
区别是是写通用模版的人需要精通不同数据库的差异去处理
还是不用模版直接由写应用的人去分别对不同的库写出相应的代码
当然，如果楼主真的精通不同数据库的话，把这种数据库之间的不同向开发人员隐藏了，那么我想会有更多的人支持它的
系统中如果大量的数据库交互都是较简单的sql，使用楼主的方法没有什么不好，提高了效率。
特别是面对客户不停修改的增加列的需求的时候。
如果系统中数据处理比较复杂的话，还是用plsql吧，它更适合，大表的多表hash，比起循环，那不是快了一点。

当然newkid的观点是数据库就是工具，不同的数据库是不同的工具，
就像刀，有菜刀，砍刀，指甲刀，虽然都有刃，但如果使用者不知道自己手里拿的是什么刀的话，可能吃亏的就会是自己。

看了楼主和newkid两位大师的精彩讨论，很受益匪浅，也就来发了两句牢骚

这话比较公道。

的确，写框架比较辛苦。少数人写了，多数人受益。既然已经写了，希望受益的人能多一些。

如果系统中数据处理比较复杂的话，还是用plsql吧：这没问题，我一直说20/80法则，DAU让你用20%的精力解决80%的问题。其余的，它支持调用存储过程。
SDBC系统有专门执行存储过程和PL/SQL块的执行函数。DAU是个C程序与数据库的接口，当你必须用C开发应用时它才有意义。
本贴讨论的是柔性程序，DAU只是这个大海的一滴水。我也希望学习到各家在不同环境下的办法。NEWKID的方法使我很受启发，原来PL/SQL可以这样用。
当然，各家有各家高招的同时，也有各自的局限，我们是在讨论，不是谁否定谁。

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

yulihua49

原帖由 newkid 于 2011-8-25 22:04 发表


这就是我以前说过的，写所谓的“复合模版”比写SQL还难，而且把一个SQL搞得支离破碎，你必须知道什么东西要写在模版，什么东西要写到应用里。
单表访问本来就很简单，用PLSQL根本没有障碍。楼主放着现成的PLSQL不用，是“制造困难”再“解决困难”。

习惯问题。
如何分解SQL，文档里有。分成列表达式，表表达式，条件表达式。还有前缀(with XXXX select),hint,......
很奇怪，为什么要分解SQL？
这是因为C，C的结构影射。你如何将关系映射到结构？一种是分析SQL，找到各语法成分与内存数据的对应，这太难了。
那么我们反过来，把各成份与内存的对应关系写好，组成SQL。
其实写起来跟直接SQL差不多。
如：直接：
SELECT
      列表达式1，
    列表达式2，
    列表达式3，
。。。。
FROM
       表表达式
WHERE
        条件表达式

元数据：
TEMPLATE 模板名 列数
     列表达式1:=类型1 [长度1 格式1]
     列表达式2:=类型2 [长度2 格式2]
     列表达式3:=类型3 [长度3 格式3]
。。。。。。
表表达式\t主键


至于条件表达式，程序里写吧。

多写了类型什么的，就省写一堆结构定义，值了。
  直观表达了数据库与内存的对应关系。不好么？
与SQL语句的对应关系也是直接的，不费事吧？
   

单表访问，无论是PL/SQL，还是SQL，如何把数据库里的数据拿到C程序变量里，始终是个麻烦。多数的办法，是弄到一堆离散的变量里。这对于后续的处理非常麻烦。
例如，从数据库得到一堆数据。传给票价计算函数，怎么办？传一堆？那么传一个数据结构，里边的成员一个一个捏。程序长，语句多，还专用。另一个表，另一个函数呢？再捏。
还有就是懒。有些表，动辄100多个字段，要写select，insert，update还各不止一个。都写列名,烦啊。麻麻盈盈一大堆，看着就晕，严重干扰程序的逻辑分析。

我们只写与本逻辑有关的列名，其他免了（映射到结构里，传给别的程序处理），使程序的可读性好得多。

[ 本帖最后由 yulihua49 于 2011-8-26 14:27 编辑 ]

newkid

原帖由 yulihua49 于 2011-8-26 11:04 发表


这完全是两码事。架构不是我定的，客户，不管是否使用DAU，或SDBC，都是那个架构，我不能干涉。（具体见71楼）
编译部署需要花点功夫也是服务器端的事。

我们再讨论一下我俩程序的事。
诚然，你基本实现了题目要求，而且代码较短。（你是把JSON写到SQL里了，代码是短，多累啊）
但是，你的代码含金量太高。非你等超级高手玩不转。试想，如果再有N多类似题目，别人来做，他一定要认真学习你的程序。那里有太多的知识点。
我的代码，都是简单语句的堆砌，任何一个粗通C和SQL的低手都能轻易看懂。（只是分页语句有点困难）。
当然，这里的形势是一边倒的，因为，能参加这个讨论的，都是武林高手。高手是不需要什么工具的。是否考虑过，如何能让低手也能轻易写出高质量程序的

试想，你的公司，能够雇一群大侠？不仅代价太高，还有一山能容几只虎的问题。大量生产的商业软件，只能使用普通劳力。
包装的作用之一，是隐藏概念。用者使用你的工具，无需了解工具的内部构造和原理。
比如，解析一个表结构，只需：DAU_init(&dau,SQL_Connect,表名，0，0）；怎么分析的，不需要知道。再写别的程序，也是这么用。这就是程序的可重用。
你的呢？，必须认真跟你学，要了解该过程的细节原理，再写自己的程序。换个数据库，DB2怎么来？再学。

我们呢？客户的程序，基本不用变的，保护了客户的智力资产。

我的代码哪有什么含金量？无非就是拼一个动态SQL, 如果我花点时间写注释，这里的人都能看懂。
即使看不懂，你就只管用好了，这好比你自己的包装器，你自己不是说“在我看来这个包装器是复杂、不用懂，免维护的”吗？你的公司不也只有一个人能维护？
这个存储过程是你按自己的思路提的需求，我工作这么多年从未碰到此类需求，我也赞同格式化的工作放到数据库之外完成。大部分存储过程都是一些简单的CRUD（create/read/update/delete）语句，和其他语言一样易懂易维护，非到万不得已我不提倡用动态SQL。
其他数据库也是这样的思路，找合适的人做合适的事。
在我看来应用开发语言的更换可能性比更换数据库更大，过不了几年又有更流行、更花哨的开发工具，如果你大部分业务逻辑写在数据库里，这才是保护了智力投资！

newkid

原帖由 yulihua49 于 2011-8-26 12:57 发表

values:{"P_ID1":"值","P_ID2":"值"}

视图能解决日期格式问题？
不同列有不同格式。
开车日期：YYYY-MM-DD
作业时间：YYYY-MM-DD HH24:MI:SS
时间戳：YYYY-MM-DD HH24：MI：SS.FF6
进站时间：YYYY-MM-DD HH24:MI

就是这样：
CREATE OR REPLACE VIEW ....
AS SELECT ...
    ,TO_CHAR(开车日期,'YYY-MM-DD') AS 开车日期
    ,TO_CHAR(作业时间,'YYYY-MM-DD HH24:MI:SS') AS 作业时间
....

这样你就在原来的表上包装了一层VIEW, 所有特殊要求都被转成了特定格式的字符串, 直接SELECT就是。你自己再定义数据字典无非也就起到这样的效果。

newkid

原帖由 yulihua49 于 2011-8-26 13:26 发表

单表访问，无论是PL/SQL，还是SQL，如何把数据库里的数据拿到C程序变量里，始终是个麻烦。多数的办法，是弄到一堆离散的变量里。这对于后续的处理非常麻烦。
例如，从数据库得到一堆数据。传给票价计算函数，怎么办？传一堆？那么传一个数据结构，里边的成员一个一个捏。程序长，语句多，还专用。另一个表，另一个函数呢？再捏。
还有就是懒。有些表，动辄100多个字段，要写select，insert，update还各不止一个。都写列名,烦啊。麻麻盈盈一大堆，看着就晕，严重干扰程序的逻辑分析。

我们只写与本逻辑有关的列名，其他免了（映射到结构里，传给别的程序处理），使程序的可读性好得多。

你还是只用自己的习惯思路。为什么要把数据“传给票价计算函数”？这些东西都让PLSQL包了，要有计价函数也是PLSQL函数。客户端很简单，就是UI而已，老老实实收集数据并传给数据库，别再费心搞什么计费函数了。

〇〇

原帖由 newkid 于 2011-8-26 22:24 发表


你还是只用自己的习惯思路。为什么要把数据“传给票价计算函数”？这些东西都让PLSQL包了，要有计价函数也是PLSQL函数。客户端很简单，就是UI而已，老老实实收集数据并传给数据库，别再费心搞什么计费函数了。

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

yulihua49

原帖由 newkid 于 2011-8-26 22:24 发表


你还是只用自己的习惯思路。为什么要把数据“传给票价计算函数”？这些东西都让PLSQL包了，要有计价函数也是PLSQL函数。客户端很简单，就是UI而已，老老实实收集数据并传给数据库，别再费心搞什么计费函数了。

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

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

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

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

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

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