|
锁定老帖子 主题：SQL 与函数式编程
精华帖 (0) :: 良好帖 (8) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-04-21
whaosoft 写道 Python 和 ruby 有什么联系吗 ?? 我只会java~
联系如上图。这是Matz，Ruby的创始人。图中他穿的T-shirt是Python Cookbook的。 =v= |
| 返回顶楼 | |
|
发表时间：2009-04-21
night_stalker 写道 看了下 sequel 的源代码，就结果而言，大家都是生成 sql 字符串，完全不理会数据库这个黑箱里头是什么 ……
我希望数据库能提供类似这样的 API： char* select(char* from, char* scope, int (*predicate)(Record*)); （predicate是函数指针） 这样就不需要解析 s-exp，不需要拼接字符串，直接传给它一个函数即可。 数据库也不需要解析 sql，大家都舒服，效率也能提升。 而且更重要的一点：易于扩展查询条件。 折衷一点方法是传一个语法解析树... 大概像这样： char* select(char* from, char* scope, Node* ast_root); mnesia:select(table, ets:fun2ms( fun(#emp{empno = E, dept = sales}) -> E end)). |
| 返回顶楼 | |
|
发表时间：2009-04-21
最后修改：2009-04-21
mnesia 好强大， query 就是 Erlang 而非 SQL
强烈的想学 Erlang 了。 zhongxuchen 写道 应该去看看陈氏查询（google一下）
这么写都是过头的，累，太累！不简洁！ sql应该脱离代码放在xml中，看了陈氏查询再做结论 请您专业点，爬完楼再回帖…… |
| 返回顶楼 | |
|
发表时间：2009-04-21
zhongxuchen 写道 应该去看看陈氏查询（google一下）
这么写都是过头的，累，太累！不简洁！ sql应该脱离代码放在xml中，看了陈氏查询再做结论 大作之前读过了。您对字符串的切割与拼装的封装确实创新，让人想到锤子与钉子的故事。 |
| 返回顶楼 | |
|
发表时间：2009-04-21
最后修改：2009-04-21
zhongxuchen 写道 我看了你们如此的讨论，说实话挺气愤一些家伙把我的优秀的陈氏查询方式从热门贴变成新手贴，让太多人还在为sql烦恼，可以查《数据库动态查询最佳实现》
<!-- 办公用品领用申请sql和hql --> <sql-query name="oa_searchOaProductAppList"> <![CDATA[ select app.*,s_users.login_name from oa_product_app app ,s_users where s_users.user_id=app.create_by and app.create_by=? #[and status=?] #[and app.create_date>=?] #[and app.create_date<=?] ]]> </sql-query> ..... 这个东西还能叫xx查询。。。我在某个javaeye的帖子里早谈过了，要叫也叫ray_linn查询了。 http://www.iteye.com/topic/233664?page=3 这种狗毛倒灶的东西就不需要自己贴金了，韩国人的项目里早有了，别污染了这个帖子。 |
| 返回顶楼 | |
|
发表时间：2009-04-21
引用 mnesia 好强大， query 就是 Erlang 而非 SQL
强烈的想学 Erlang 了。 其实不是Erlang函数,fun2ms会把函数转换成match specification.类似sql,只不过这个东西比SQL还丑。 之所以你觉得SQL和FP非常吻合，是因为他们都是基于数据流模型的.流动的数据，静止的指令.命令式语言是基于指令流的模式,指令是流动的,数据是静止的.命令式语言与SQL之间的失配的根源也在于此,命令式语言的默认前提假设是，数据的流动方向与时序无关的先天无法预测的，于是它要求控制器在一个时沿上往任意方向写数据.但是有很多情况下,数据的流动方向是与时序相一致,指令流的模式就显得冗余。 |
| 返回顶楼 | |
|
发表时间：2009-04-21
Trustno1 写道 其实不是Erlang函数,fun2ms会把函数转换成match specification.类似sql,只不过这个东西比SQL还丑。 之所以你觉得SQL和FP非常吻合，是因为他们都是基于数据流模型的.流动的数据，静止的指令.命令式语言是基于指令流的模式,指令是流动的,数据是静止的.命令式语言与SQL之间的失配的根源也在于此,命令式语言的默认前提假设是，数据的流动方向与时序无关的先天无法预测的，于是它要求控制器在一个时沿上往任意方向写数据.但是有很多情况下,数据的流动方向是与时序相一致,指令流的模式就显得冗余。 想请教下 match spec 难看的原因何在…… 还有 mnesia 是怎么处理 match spec 的？ 关于数据流模型和指令流模型，有比较科普的文章介绍吗？ |
| 返回顶楼 | |
|
发表时间：2009-04-21
引用 想请教下 match spec 难看的原因何在…… 还有 mnesia 是怎么处理 match spec 的？
关于数据流模型和指令流模型，有比较科普的文章介绍吗？ 可能那帮人天生是搞通信的料,比特位的痕迹非常重. 指令流你想象成选豆子，一个笨蛋是拿一粒比一下小的放右边大的放左边.数据流想象成筛豆子,另外一个笨蛋在簸箕上扎了一个个洞,让一堆豆子从上往下掉，于是分成了掉下去的和掉不下去的. |
| 返回顶楼 | |
|
发表时间：2009-04-22
最后修改：2009-04-22
to night_stalker: QuakeWang说的ambition就是干这个的
QuakeWang 写道 在ActiveRecord上有类似的adpater:
http://defunkt.github.com/ambition/adapters/activerecord.html ambition下面用了parse_tree，不知道ruby1.9的支持怎样了. 看来聪明人不谋而合 
DataMapper的例子： User.all(:age.gt > 3) 这种“结构式”的表达方法，利于adapter对意图的理解并分别作不同的解释（比如couchdb_adapter）,相比ActiveRecord直接生成Sql要好： User.all(:conditions => ["age > ?", 3]) |
| 返回顶楼 | |
|
发表时间：2009-04-22
最后修改：2009-04-22
ambition 和 sequel 都用 ParseTree。
ruby 本身不提供让你直接看 proc 源代码的功能， PrseTree 的核心是一个用 C 写的扩展，可以在虚拟机中挖出语法树来。 但是！FX 告诉我：MRI 1.9 只保存序列化的 YARV 字节码，不再保存 ParseTree 了，所以 ParseTree 没戏了…… 泪啊，看人家 linq 多稳定！ 不过这里用的 sxp 不受影响（它是靠 method_missing 实现 parse tree 的） 但是 method_missing 的缺点就是没法中缀编写 && 和 || （因为这两个东西不是 method） 只能用 _and(a,b) 和 _or(a,b)。或许可以设计个不太别扭的写法 ？ 如 Topic.select{:a < 12}.and{:a > 5}.all …… 有点像 criteria 了，不好看…… DataMapper 的实现简单一些，不涉及 ParseTree，但是看起来也别扭一些。 为了弥补 parsetree 的缺席，1.9 自带了 Ripper 库。 但它很弱，只能解析字符串（如 "id < 12 && id > 5"），没法解析语句（如 proc{:id < 12 && :id > 5}）。 可以想到的一个简单 hack： 先从 Proc#source_location 定位出 proc 的位置。（此方法返回 [文件名，行号]，如： ["topic.rb",31]） 然后读取源文件，从这个地方开始截取这个完整的 proc 字符串作解析…… 此 hack 的缺点是 irb 、打包的 jruby 都不认。而且很土。 （嗯…… 性能不是问题，可以用 "文件名：行号" 索引缓存的 match spec） |
| 返回顶楼 | |
