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

yulihua49

原帖由 cszxheap 于 2011-8-25 10:40 发表
一看标题，就知道是原先话题的 n V n 了，呵呵。
lz的柔性，强调了不更改服务器端“处理过程”而进行“透明数据采集”的目的，这里的强调的是采集，自身负责的数据传输完成，这个“传输层”任务就结束了，这里我同样有和kid的疑虑，作为软件服务商，你的业务逻辑后续处理难道真的都在client端？如果不是，谁来帮你做？如果是，可是诸多弊处。。。。。
kid的处理原则是物尽其用，被tom影响的不浅。

我们一般的说，数据访问逻辑在服务器，事务、并发、锁的控制等。大部分业务逻辑在客户端，用JAVA写搞JAVA的人比较多，改起来也快。C的人很少，所以服务器尽量少维护。

由客户端提交命令，做什么，服务器解决怎么做，返回结果。
比方说，客户端要一批票，参数提交到服务器。服务器根据规则取票，它只关心几个字段，完成后把大部分字段返回客户端。这些字段它并不关心。在客户端，他们会显示在屏幕上经过进一步交易打印在票面上，这都不是服务器的活。票面上可能要增加些内容，这时数据库表结构可能会增加几个字段，屏幕和打印机也是，但与服务器无关。这种更改是经常的，往往涉及很多表。如果全是存储过程，要改的太多了。对于DAU来说，只要重新生成一下模板，程序逻辑修改极少，重新编译即可。我们的模板都在一个单独的数据模块中，很容易更换。

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

qingyun

呵呵，我是newKid兄的铁杆支持者；
不过做项目的时候，确实不少精力花在前端；
向 yulihua49 这样对data maping引擎以及业务封装的水平，反而更加稀缺；

〇〇

统每年都会更新下，号称全部改造，然后上亿的收入就来了，哈哈，

newkid

原帖由 yulihua49 于 2011-8-25 10:16 发表


很好很强大，这是柔性的了。学习一下再说。
执行时间？参考一下，我是担心正则表达式的性能。
分析表结构与生成语句揉在一起了。我是分开的，可以在不同场合用，也可以分析一次生成各种语句，插入啊，修改啊什么的，只是这个例子没这么用。
max和min用绑定变量，这个比我好，我将来可以改。

里边to_char啥的还得写，而且各dtime格式不一定相同（我是模板制定的）。我的那些都自动生成不用写的。

绑定变量的个数不会很多，比如你的例子里面就只有一个，这个拼装SQL（包括规则表达式）的开销可以忽略。
我对你的传变量方式不满意，比如WHERE ID>=:P_ID1 AND ID<=:P_ID2 后面的VALUES怎么传？我如果来设计接口就不这么传，我会用变量名而不是列名，因此里面也用不到REGEXP_REPLACE, 用REPLACE就行。
你的模版无非就是自己又定义一套字典。如果我对某个日期格式有特殊要求我可以创建一个视图。

newkid

原帖由 yulihua49 于 2011-8-25 10:53 发表

目前主要是担心JAVA服务器的稳定性，怕出个奥运门票事件什么的。
还有是性能。
07年公司做几种产品的压力测试，没敢让JAVA参加。

敢不敢让PLSQL参加？

newkid

原帖由 yulihua49 于 2011-8-25 11:20 发表

我们在讨论技术实现和原理，涉及内容多一些显得复杂。实际上，几个学生来我们这参加项目，一点数据库不懂，也没说什么DAU，给个DEMO，讲一下任务。
自己照猫画虎，干的挺好，几乎是0培训。
因为是源码，编译部署需要花点功夫。使用是极其简单的。
在我看来这个包装器是复杂、不用懂，免维护的。

你也知道“编译部署需要花点功夫”，那还把业务逻辑写在客户端？

newkid

原帖由 昨夜袜子 于 2011-8-25 10:23 发表
是不是可以这么说：除去取全表数据必须写模板不论是用你的自动生成的sql，或者原本已经是sql不用生成
（原帖上说中对select开头的做了处理没对其他做处理不知道是否有改进）。也就是说别人写sql你写模板而已。
而且在我看来模板异常难写必须指定类型，长度，名称，长度是用来复制数据时定界用的（不知是否正确没看到
具体代码猜测），如果是这样的话，那这个长度异常重要例如：两个长度15的字串而在模板中定义成14,16。
你会发现有时结果是正确的有时是错误的（和你两个字串的数据有关，和你拷贝数据的顺序有关）。
还有就是你的包装现在应该是只针对oracle并不具备你所说的数据度独立性（或许根本就没有这个需求）。

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

yulihua49

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

你也知道“编译部署需要花点功夫”，那还把业务逻辑写在客户端？

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

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

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

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

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

nannan5000

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


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

像 yulihua49  这样的大牛，写出这种类似DTO的模板
还是很有想法的。

我觉得 他搞成这样，完全没有必要再用Oracle，用MySQL就ok。

yulihua49

原帖由 nannan5000 于 2011-8-26 11:06 发表




像 yulihua49  这样的大牛，写出这种类似DTO的模板
还是很有想法的。

我觉得 他搞成这样，完全没有必要再用Oracle，用MySQL就ok。

性能问题。还是ORACLE性能高。如果客户认为MYSQL够用了，我很愿意提供MYSQL接口。
做MYSQL也很有意义，项目初期，可以MYSQL，后来业务发展了，升级ORACLE很方便。
铁科研用SYBASE，存储过程。要想升级ORACLE，比较困难了。

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