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

yulihua49

原帖由 newkid 于 2011-9-2 21:35 发表
"比如，有些人喜欢用大小写列名，select时需加引号。DAU自动处理的，你的程序若处理这些，又得增加代码。
有些人怕别人盗取数据逻辑，采用如MG0001，LP0002这样不可懂的列名，一个表百十来个。要是手写列名，。。。。。。。"
这个问题好像以前也讨论过。不要忘了，用户才是应用和数据的真正主人。你在数据库里设置的种种障碍最后只会搬起石头砸了自己的脚。你在开发、调试的时候需要看数据吧，要不怎么知道事务正确写入了？这时候看到一堆莫名其妙的列名会很爽？再说这种低级的“保密”手段也很搞笑，你敢不给设计文档？如果你的商业对手需要，自有手段搞到，你只是为自己和用户添堵。（我完全同意。但这是客户的想法，后来也改了。之前有人这么做。之后也可能有人这么做，我只不过提供一点支持而已）。

“最后你也承认，PL/SQL不提倡动态语句，最好处理裸数据。这就承认了，这种高度柔软的程序，不适合PL/SQL做。”
我也用动态SQL, 但不是用于这种低层次的包装，我用它处理组合查询，用较少的代码应付大量的组合条件。PL/SQL能伸能缩，亦柔亦刚，SCALABILITY与FLEXIBILITY兼备，实乃人间第一神器也！

“实践表明，DAU在大规模并发事务处理中具有明显优势。”
你的优势其实是ORACLE在并发性能方面的优势，不是你的DAU，你那些事务用PLSQL来实现还更有优势。

“sql抛弃了，就没有数据检索了吗？那么，在SQL出现之前，计算机不处理数据检索吗？”
话是这么说，但没有人希望走回头路吧？

“用PL/SQL，不一定要用存储过程。”
难道用匿名块，每次都重编译？


“原教旨主义者攻击异教徒了。
说话是有语义环境的。在说数据存取吗？”
奥哦，不知道你心灵这么脆弱，我以为你很皮实呢。你给我扣“原教旨主义者”的帽子我也不过一笑置之。你要是能找到有趣的漫画来攻击我，我倒是很乐意看看的。

noSQL是历史长河的一朵小小浪花，我们注意到它。稍微有点往回卷（历史倒退）。未对其前途进行评估。
只说其可能。。。。。。。就程序的柔性而言，未必比SQL好。
就我那个通用统计脚本语言而言，最初就是在noSQL的关系数据库上开发的。后来还是发现SQL对它更适合。
。。。。。
DAU就是利用了基本数据库的优势，这并不矛盾。PL/SQL我不敢说。但TRS使用SYBASE，存储过程，问题已经非常明显，如果你春运期间在中国买火车票，你很有可能突遇故障，交易缓慢甚至停顿。据铁科研客票组分析，原因之一是存储过程处理临时表造成系统表锁定。
另外就是系统处理压力完全在数据库引擎，无法分担。当然还有其它原因。最主要就是数据库选择不当。现在想换数据库，不可能了。
因为用了存储过程，改换门庭不是一个容易的事。试想如果当年使用了某种独立于数据库的框架，现在换ORACLE就容易多了。
鉴于这个教训，才有研发柔性框架的思想。
将来如果有比ORACLE更好的数据库出现呢？

当年INFORMIX最好，后来它没落了。现在ORACLE最好（性能最高）。DB2正在赶上来，某些方面比ORA强，总体还是差一些。
将来，不好说。

ODBC和JDBC当然是独立于数据库的，但是它把几乎全部业务逻辑放在客户端，这种低效的安排，是你我都不提倡的。

提高效率的方法是，客户端只给服务器传送命令，服务器返回最终结果。中间过程就不要在网络上传输了。
解决办法有两个，存储过程或3层C/S，即C/S/S模型。我是在为C/S/S提供工具。DAU支持存储过程，这样，一个业务逻辑，你可以写在存储过程，也可以写在应用服务层，都很方便。你可以两个都写出来，比较测试，得到自己的结论，比在这里打嘴仗有效得多。

[ 本帖最后由 yulihua49 于 2011-9-4 10:46 编辑 ]

yulihua49

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

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

为什么要弄沉？

〇〇

就你们俩论战不累，我们看得累了

newkid

SYBASE的并发问题不是存储过程的错，是读写互相阻塞的问题，你的DAU也不能解决。

“但是它把几乎全部业务逻辑放在客户端，这种低效的安排，是你我都不提倡的。”
不会吧？你怎么转变这么快？你分明是提倡把业务逻辑放在客户端的嘛，还美其名曰“分布式计算”。

我在以前单位也用存储过程和其他方式PK过，从未落败。

newkid

原帖由 〇〇 于 2011-9-4 21:14 发表
就你们俩论战不累，我们看得累了

可以不看嘛。

〇〇

trs是做网站的？

yulihua49

原帖由 〇〇 于 2011-9-5 06:21 发表
trs是做网站的？

客票预订系统。

yulihua49

原帖由 newkid 于 2011-9-4 23:36 发表
SYBASE的并发问题不是存储过程的错，是读写互相阻塞的问题，你的DAU也不能解决。

“但是它把几乎全部业务逻辑放在客户端，这种低效的安排，是你我都不提倡的。”
不会吧？你怎么转变这么快？你分明是提倡把业务逻辑放在客户端的嘛，还美其名曰“分布式计算”。

我在以前单位也用存储过程和其他方式PK过，从未落败。

不是啊，我一直提倡C/S/S啊，一个交易，要访问很多次数据库。都在客户端做，很差劲的。所以无论是我们当年的软件，还是TRS，都没有采用ODBC。
TRS是存储过程，我们是C/S/S。但是铁道部很多其他系统，有很多是采用ODBC，JDBC的，网络表现就是很差劲。

其实C/S/S也是存储过程，不过不是PL/SQL，而是其它语言。ORACLE也提供了JAVA，C的存储过程。

分布是趋势，分布到什么粒度，是可以思考的。SDBC提供各种粒度的分布。具体由使用者自行决定。
可以每个SQL的发请求，也可以一个交易，若干SQL打包写在应用服务层。也可以一个交易，若干SQL打包写在存储过程。都支持。混合使用各种方法也行。
如果发现DAU方便，就在应用服务层写DAU。否则，写存储过程也没问题，我提供方便的调用接口。

反正如今写SQL可以不（怎么）手写列名了，这提供了柔性的捷径。你非常热爱反复的枚举列名，没人限制你。

你写的那个存储过程，有空我试试。要测一下大并发的压力测试。
就这个服务来说，对性能要求不高。我那个程序性能也不高（主要是分析表结构开销太大了）。
我分析了列，主键，列属性修改表（自定义的），分析的内容比你多，所以性能上可能会吃点亏。

[ 本帖最后由 yulihua49 于 2011-9-5 12:14 编辑 ]

newkid

你的所谓C/S/S，中间那个S是你做的表到结构的映射，不含业务逻辑；后面那个S你认为是存储，可以是任何数据库甚至文件系统，也不含业务逻辑。那么业务逻辑不就落到了C也就是CLIENT身上？怎么又变成了存储过程？
ORACLE的JAVA，C过程还是存储过程的扩展，和PLSQL属于同一层。
你说的“柔性”只适合工具类或接口类程序，业务程序必须知道访问什么列名，就像你的客户程序里要使用结构的成员名称来引用数据。

〇〇

原帖由 newkid 于 2011-9-5 22:38 发表
你的所谓C/S/S，中间那个S是你做的表到结构的映射，不含业务逻辑；后面那个S你认为是存储，可以是任何数据库甚至文件系统，也不含业务逻辑。那么业务逻辑不就落到了C也就是CLIENT身上？怎么又变成了存储过程？
ORACLE的JAVA，C过程还是存储过程的扩展，和PLSQL属于同一层。
你说的“柔性”只适合工具类或接口类程序，业务程序必须知道访问什么列名，就像你的客户程序里要使用结构的成员名称来引用数据。

中间那个S是拼SQL。。。
干脆再办个比赛好了，双方商量数据库表结构和数据生成规律...