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

newkid

"我们要支持：不仅分散，而且分布。"分散/分布就意味着丧失了中心掌控权，还有维护的问题。程序版本如何统一？数据缓存何时刷新？比方你前面提到的本地缓存计费表，要是修改了要怎么通知客户端？不是得有一套复杂的同步、发布系统？业务逻辑集中是大势所趋，即使不集中在数据库也集中在应用服务器，你们那种设计思想迟早是要遭淘汰的。

“你虽然也写了个柔性的程序，可是可读性呢？”
你怎么不拿DAU_toJSON来比较？你可以“封装了，看不见”我当然也可以声称这个存储过程是“封装了，看不见”，你只需“无数次使用”。
至于动态SQL，可读性肯定要打个折扣，这就是我为什么说要尽量避免，具体到业务逻辑的存储过程基本上应该消灭动态代码。
至于这个过程做的事情，坦率地说我百分百赞成拿到数据库外面去做，因为它只是个格式上的包装而已。PLSQL应该处理“裸”数据。我说的存储过程其实包括了你现在用客户端在做的大部分事情。只是我不需要在PLSQL和SQL代码之间硬插入一个类似你的DAU那样的层，就算这一层“柔情万种”也毫无用处。

“没有模板，我怎么解释你的结果集？”
我就不明白了，每个游标不都有列名吗？你就是访问一个二维结果集，为什么就无法解释？

“有了模板，用你这程序干啥？问题已经解决了。”
有了模版你无非就是拿到数据而已，还得用数据干活呢？忘了你还有客户端代码了？你这个传输层接口除了传输之外能解决啥问题？


“ORACLE是按系统性能收费的。”
我虽然不太懂他们的定价策略，但应该是按CPU来算吧？我的建议无非就是物尽其用，ORACLE又不会对PLSQL另外收费。原来有什么硬件，使用了存储过程还是一样的硬件，不需要额外的什么强力服务器。

“我们那帮ORACLE的售前，问他们，是否存储过程性能更好，都是支支吾吾的。”
我很有兴趣他们怎么个“支支吾吾”法？不过呢，售前的基本功就是察言观色，投其所好，你爱听什么他们就捡什么说，只要能卖出系统就成。


“文中提到，随着ORM兴起，SQL越来越像noSQL,....”
哈哈，自作多情，给个越来越像noSQL的例子看看？XML出现的时候也有人说SQL要灭亡了，现在呢？走着瞧吧。

"另外，我懒得写SQL的列名，同样懒得写JSON的对象名（还有那些标点符号）。
DAU_insert(),DAU_select(),DAU_toJSON(),DAU_fromJSON(),多好，啥名也不写。（客户端写了，我为啥还要重复写？）"
所以你这套东西只对你那种胖客户的设计思想有用，一旦访问SQL已经很方便（比如在PLSQL里）这套东西就完全无用。

newkid

突然想起ORACLE有个SPACIAL产品，GIS现在也被集成到数据库中了，和XML一样。

yulihua49

拜读了，不过你未能说服我。在分布式系统里，你给的工具，单一的PL/SQL不够用。
分布中的各种问题，客户们自有解决办法，我们只需提供技术支持。
顺便说一句，你那个程序处理JSON是有缺陷的。如果数据里含有JSON的符号，需要转义，JSON有转义规则。
我那个东西不必贴出来了，有json-c-0.9下载源码看看吧。

ORACLE的GIS，我可以跟开发组提及一下。不过人家用的现成的库，不一定要在ORACLE上做。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。

有了模板，处理数据比PL/SQL方便多了，还可以在其他机器上进行，不占用数据库引擎，没必要PL/SQL了。再者，我也可以发PL/SQL块，不一定非要存储过程。
当然也可以调用存储过程，各种手段都支持。使用哪种是客户的事。
我的局限就是用在C服务器/客户端，JAVA的客户端。在这个范畴内可以使用这个工具，可以方便的柔性，在柔性的同时保证效率和安全性可靠性。
我没说必须，只说可以。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
“哈哈，自作多情，给个越来越像noSQL的例子看看？XML出现的时候也有人说SQL要灭亡了，现在呢？走着瞧吧”
1.不是我，是原文。2.我也说了，各种手段会长期共存。

noSQL是啥？只要不是SQL，都是noSQL。
特点是不用语句，准备了KEY就FIND，直接操作。像noSQL就不是noSQL，就是基本不使用SQL。
ORM也好SRM也好，都减少了SQL语句的使用，有些代码完全看不到SQL。你不让我拉出来的那个通用加载卸载程序，就完全没有写SQL语句。
表面上没有SQL，打开包装一看，还是SQL，所以说像，而不是。

[ 本帖最后由 yulihua49 于 2011-9-1 11:26 编辑 ]

newkid

"顺便说一句，你那个程序处理JSON是有缺陷的。如果数据里含有JSON的符号，需要转义，JSON有转义规则。"
转义字符可以先用REPLACE处理。当然这样也不是100%严密，有可能字符串本身就包含转义过的字符。我是不赞成在数据库里面干这个的，写那个过程只是玩票而已。

"noSQL是啥？只要不是SQL，都是noSQL。"
这个定义倒是简洁，这么说你就是noSQL大师了，还有楼下卖茶叶蛋的老太太也是noSQL大师：
http://www.itpub.net/thread-1393823-1-1.html

nannan5000

原帖由 yulihua49 于 2011-9-1 11:04 发表

noSQL是啥？只要不是SQL，都是noSQL。
特点是不用语句，准备了KEY就FIND，直接操作。像noSQL就不是noSQL，就是基本不使用SQL。
ORM也好SRM也好，都减少了SQL语句的使用，有些代码完全看不到SQL。你不让我拉出来的那个通用加载卸载程序，就完全没有写SQL语句。
表面上没有SQL，打开包装一看，还是SQL，所以说像，而不是。

为啥直接key find呢？
sql都抛弃了

kv存储 不是搞的数据更凌乱了么？

yulihua49

原帖由 newkid 于 2011-8-31 22:30 发表
“没有模板，我怎么解释你的结果集？”
我就不明白了，每个游标不都有列名吗？你就是访问一个二维结果集，为什么就无法解释？

“有了模板，用你这程序干啥？问题已经解决了。”
有了模版你无非就是拿到数据而已，还得用数据干活呢？忘了你还有客户端代码了？你这个传输层接口除了传输之外能解决啥问题？

“我们那帮ORACLE的售前，问他们，是否存储过程性能更好，都是支支吾吾的。”
我很有兴趣他们怎么个“支支吾吾”法？不过呢，售前的基本功就是察言观色，投其所好，你爱听什么他们就捡什么说，只要能卖出系统就成。


"另外，我懒得写SQL的列名，同样懒得写JSON的对象名（还有那些标点符号）。
DAU_insert(),DAU_select(),DAU_toJSON(),DAU_fromJSON(),多好，啥名也不写。（客户端写了，我为啥还要重复写？）"
所以你这套东西只对你那种胖客户的设计思想有用，一旦访问SQL已经很方便（比如在PLSQL里）这套东西就完全无用。

胖客户端也是分布式应用的一种，不是我那种，是一个潮流。
游标里确有列名，但是需要一些代码，循环处理每个列。不像DAU，一句话搞定。
另外，实际中有很多情况，DAU都处理了。你要在这处理会很麻烦。
比如，有些人喜欢用大小写列名，select时需加引号。DAU自动处理的，你的程序若处理这些，又得增加代码。
有些人怕别人盗取数据逻辑，采用如MG0001，LP0002这样不可懂的列名，一个表百十来个。要是手写列名，。。。。。。。
客户端不想建立这样不可懂的对象，希望JSON采用可懂对象名。
DAU在生成模板时，会有一个列格式修改功能。有一个表，描述何表，何列，采用何类型、长度、格式、伪列名。。。生成模板时就把这些问题处理了。
在结构/对象里，采用你定义的伪列名。

最后你也承认，PL/SQL不提倡动态语句，最好处理裸数据。这就承认了，这种高度柔软的程序，不适合PL/SQL做。

当年，我们完全是在技术讨论的场合，与商务无关。（而且是已经确定ORACLE了）。
之前，就是在C/S/S模式下，使用TUXEDO，数十台客户机模拟成千的客户端并发访问的压力测试，他们也是用PRO*C，并未采用存储过程。
4台HP小型机做RAC，N台小型机作TUXEDO。所云大概是，（记不清了），存储过程在静态语句的预编译方面有优势，但在大规模并发处理环境，没有测试结论。
实践表明，DAU在大规模并发事务处理中具有明显优势。

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

yulihua49

原帖由 nannan5000 于 2011-9-2 08:28 发表



为啥直接key find呢？
sql都抛弃了

kv存储 不是搞的数据更凌乱了么？

简单的应用，noSQL有优势。
sql抛弃了，就没有数据检索了吗？那么，在SQL出现之前，计算机不处理数据检索吗？
即使是关系数据库，也不一定要SQL，早年头的DBASE，就流行很广。当年INFORMIX就有一个关系接口API，叫ALL的。也是noSQL的关系数据库。

存取和检索数据，不一定要用关系数据库。
用关系数据库，不一定要用SQL。
用SQL，不一定要用ORACLE。
用ORACLE，不一定要用PL/SQL。
用PL/SQL，不一定要用存储过程。

[ 本帖最后由 yulihua49 于 2011-9-2 13:39 编辑 ]

yulihua49

原帖由 newkid 于 2011-9-1 22:42 发表
"noSQL是啥？只要不是SQL，都是noSQL。"
这个定义倒是简洁，这么说你就是noSQL大师了，还有楼下卖茶叶蛋的老太太也是noSQL大师：
http://www.itpub.net/thread-1393823-1-1.html

原教旨主义者攻击异教徒了。
说话是有语义环境的。在说数据存取吗？

[ 本帖最后由 yulihua49 于 2011-9-2 11:45 编辑 ]

newkid

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

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

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

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

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


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

qingyun

两位专家真是有空，打得不可开交；
有了里面，坛子才更加热起来；

真的羡慕；论坛里吵吵架，真的很幸福，也是是自娱自乐了；

不过很多打工仔没那么多得闲情雅致，总被工作折腾的半死不活；