我偶尔会听到关于SQL如何糟糕而且它不是一种好语言的事情,但我从来没有真正听到过关于它的替代方案.那么,是否有其他优秀的语言可以实现相同的目的(数据库访问),是什么让它们比SQL更好？有没有好的数据库使用这种替代语言？
编辑:我熟悉SQL并一直使用它.我没有问题,我只对可能存在的任何替代方案感兴趣,以及为什么人们更喜欢它们.
我也不是在寻找替代类型的数据库(NoSQL运动),只是寻找不同的数据库访问方式.
我当然同意SQL的语法难以使用,无论是从自动生成它的角度,还是从解析它的角度来看,如果我们根据我们的要求设计SQL,那么我们今天要编写的语言风格就不是了.在今天.如果我们今天设计语言,我认为我们不会发现这么多不同的关键字,我怀疑连接语法会有所不同,函数GROUP_CONCAT会有更多的常规语法,而不是在括号中间添加更多关键字来控制其行为...如果我们今天重新设计了这种语言,那么在SQL中创建自己的不一致和冗余的清单,你希望/希望看到这些不一致和冗余.
对于与关系数据库(即SQL作为协议)说话,没有任何SQL替代方案,但在应用程序中编写SQL有很多选择.这些替代方案已经以前端的形式实现,用于处理关系数据库.前端的一些示例包括:
SchemeQL和CLSQL,由于它们的Lisp遗产,可能是最灵活的,但它们看起来更像SQL而不是其他前端.
LINQ(在.Net中)
ScalaQL和ScalaQuery(在Scala中)
Ruby中的SqlStatement,ActiveRecord和许多其他人,
HaskellDB
......这个列表继续用于许多其他语言.
我认为今天的基本主题是,我们不是用一种新的查询语言替换SQL,而是创建特定于语言的前端来隐藏我们常规的日常编程语言中的SQL,并将SQL视为与关系进行交谈的协议.数据库.
看看这个清单.
Hibernate查询语言可能是最常见的.Hibernate的优点是对象非常容易(几乎自动地)映射到关系数据库,开发人员不必花费太多时间来进行数据库设计.查看Hibernate网站了解更多信息.我相信其他人会使用其他有趣的查询语言...
当然,那里有很多NoSQL的东西,但你特别提到你对那些不感兴趣.
也许你正在考虑批评C. Date和他的朋友们已经反对现有的关系数据库和SQL; 他们说系统和语言不是100%关系,应该是.我真的没有看到任何真正的问题; 据我所知,你可以拥有一个100%的关系系统,如果你愿意,只需要训练你使用SQL的方式.
我个人经常遇到的是缺乏表达能力SQL继承自其理论基础,关系代数.一个问题是缺乏对使用域排序的支持,当您处理由日期,时间戳等标记的数据时,您会遇到这种情况.我曾经尝试在一个充满时间戳的数据库上完全用普通的SQL做一个报告应用程序,这是不可行的.另一个原因是缺乏对路径遍历的支持:我的大部分数据看起来都像是需要遍历路径的有向图,而SQL无法做到这一点.(它缺少"传递性闭包".SQL-1999可以用"递归子查询"来实现它,但我还没有在实际使用中看到它们.还有各种黑客可以使SQL应对但是它们很难看.)这些问题是顺便提一下,还有一些Date的着作讨论过.
最近我被指出.QL似乎很好地解决了传递闭包问题,但我不知道它是否可以解决有序域的问题.
"我偶尔会听到有关SQL如何糟糕而且它不是一种好语言的事情"
SQL已有三十多年的历史.关于"哪些特征使某些东西成为'好'语言以及哪些特征使其成为'坏'语言"的见解比SQL本身发展得更快.
此外,SQL不是一种符合当前"关系需要什么"标准的语言,因此,SQL不是一种关系语言来启动.
"但我从来没有真正听说过它的替代品."
我邀请您思考一下您是否只想在错误的地方(即商业DBMS行业专门)听到的可能性.
"那么,是否有其他优秀的语言可以实现相同的目的(数据库访问),是什么让它们比SQL更好？"
Date和Darwen描述了现代数据处理语言在其"第三宣言"中必须遵循的特征,其最新版本在其"数据库,类型和关系模型"一书中有所规定.
"有没有好的数据库使用这种替代语言？"
如果"好",你的意思是"工业强度",那么没有.最接近的可能是Dataphor.
Rel项目提供了"数据库,类型和关系模型"中定义的Tutorial D语言的实现,但Rel的当前主要目标是教育性质.
我的SIRA_PRISE项目提供了"真正的关系型"数据管理的实现,但我也不愿将其标记为"语言的实现".
当然,您也可能会像一些人提出的那样研究一些非关系型的东西,但我个人认为非关系型数据管理是数十年的技术回归.不值得考虑,就是这样.
哦,顺便说一句,用于管理数据库的软件系统不是"数据库",而是"数据库管理系统",简称"DBMS".就像照片与相机不一样,如果你正在讨论相机,并且你想避免混淆,那么你应该使用正确的单词"相机"而不是"照片".
看看 LINQ to SQL ......
几个月前试过了,从未回头......
直接回答:我认为那里没有任何认真的竞争者.DBase及其模仿者(Foxpro,Codebase等)暂时是一个竞争者,但我认为他们基本上失去了数据库查询语言的战争.还有许多其他数据库产品都有自己的查询语言,比如Progress和Paradox以及其他几个我用过的名字我不记得了,还有更多我从未听说过的名字.但我不认为任何其他竞争者甚至接近获得市场的非平凡份额.
作为数据库格式和查询语言之间存在差异的简单证据,我使用的DBase的最新版本 - 多年前现在 - 提供了"传统的"DBase查询语言和SQL,两者都可以使用访问相同的数据.
Side ramble:我不会说SQL很糟糕,但它有很多缺陷.凭借我们现在拥有的多年经验和后见之明,我相信我可以设计出更好的查询语言.但是创建一种更好的查询语言并说服人们使用它是两回事.是否足以说服人们认为值得学习的麻烦.人们花了很多年的时间学习如何有效地使用SQL.即使您的新语言更易于使用,也肯定会有学习曲线.您将如何将现有系统从SQL迁移到新语言？等等.当然,就像C++,C#和Java一样,它已经在很大程度上推翻了COBOL和FORTRAN.但它需要结合技术优势和良好的营销才能实现这一目标.
尽管如此,我还是嘲笑那些在任何人批评它的时候都急于防守SQL的人,他们坚持认为你对SQL的任何问题必须是你自己使用它的无能而不是SQL的任何错误,你必须没有达到理解其完美所必需的更高层面等等.冷静下来,深吸一口气:我们侮辱计算机语言,而不是你的母亲.
这些日子的一般运动是NoSQL; 通常这些技术是:
分布式"哈希表",用于将数据存储为键/值对
面向文档的数据库
就个人而言,只要符合您的需求,我认为SQL没有任何问题.SQL具有表现力,非常适合处理结构化数据.
早在20世纪80年代,ObjectStore就提供了透明的对象访问.它有点像RDBMS加上ORM,除了没有所有那些额外的漏洞抽象层:它直接将对象存储在数据库中.
因此,这种替代方案实际上"根本就没有语言",或者可能是"您已经使用的语言".您可以编写C++代码并创建或遍历对象,就像它们是本机对象一样,数据库会根据需要处理所有内容.有点像ActiveRecord,但它实际上和ActiveRecord营销blitzes声称一样好.:-)
(当然,它没有甲骨文的营销力量,而且它没有MySQL的零成本,所以每个人都忽略了它.现在我们尝试用RDBMS和ORM复制它,有些人试图争论那些表实际上有意义的存储对象,并编写巨型XML文件告诉您的计算机如何将对象映射到表是一种合理的解决方案.)
我想你可能有兴趣看看Dataphor,它是一个开源的关系开发环境,有自己的数据库服务器(说D),并且能够从它的查询语言派生用户界面.
此外,看起来 Ingres仍然支持QUEL,它是开源的.
京公网安备 11010802040832号 | 京ICP备19059560号-6 