为什么没有数据库完全支持ANSI或ISO SQL标准？
如果我在devise一个炼油厂，我不会期望来自不同供应商的材料不会以微妙而重要的方式遵守公布的标准。 来自一个供应商的pipe道，阀门和其他部件可能会带有符合ANSI标准的法兰和壁厚，同样来自任何其他供应商的部件也是如此。 因此互操作性和系统安全性得到保证。
那么为什么常见的数据库对于他们所遵守的标准的哪些部分是如此挑剔，以及为什么没有100％符合标准的系统脱颖而出呢？ 标准是否被打破，缺乏范围或难以devise？
得出这个结论; ANSI（或ISO）定义SQL标准的重点是什么？
编辑： 常用数据库之间的实现差异列表
在软件行业，你有一些真正标准的标准，也就是说，不符合标准的产品是不行的。 文件规格属于该类别。 但是，你也有更像标准的“标准”：它们可以定义为逐点定义的标准，但是通常只是部分实施，或者有显着差异。 Web开发充满了诸如HTML，CSS和“ECMAScript”这样的“标准”，其中不同的供应商（即网页浏览器）不同地实施标准。
这种变化会引起头痛，但是标准化仍然会带来好处。 想象一下，如果没有HTML标准，每个浏览器都使用自己的标记语言。 同样，想象一下，如果没有SQL标准，每个数据库供应商都使用自己的专有查询语言。 将会有更多的供应商locking，开发人员在处理多个产品方面会遇到很多困难。
所以，不，ANSI SQL不符合ANSI标准在其他行业中的相同目的。 但是它确实有用。
可能是因为标准一致性对于数据库系统购买者而言是低优先级的。 他们更感兴趣的是：
- 与已有的兼容性
- 性能
- 价钱
- OS支持
仅举几个例子。
编程语言也是如此 – 很less（如果有的话）编译器支持当前ANSI C和C ++标准的每一个特征。
至于为什么要打标准，大多数供应商最终都会提供标准的支持。 例如，大多数供应商支持或多或less的所有SQL89。 这允许供应商在他们的规格表上勾选一个（相对不重要的）checkbox，并且允许像我这样有兴趣编写可移植代码的人这样做，虽然不得不放弃大量的花里胡哨。
请参阅文章“ IS SQL是一个真正的标准ANYMORE？” 讨论关于SQL标准的当前（2005）问题。
事实上，ANSI SQL标准并不经常被遵循。 刚刚读过SO：大多数SQL线程从来没有提到标准，例如，有关networking协议的讨论通常包括相关RFC的实际报价，章节和诗句。
我一直怀疑，其中一个原因是SQL标准不是免费分发的。 简单地得到它不是微不足道的。 各种非官方的副本浮动。）
另一个原因是这是一个非常复杂的文本，组织不佳。 它使用一个奇怪的词汇（如“authID”，而不是“用户”）。 为了理解标准（“SQL标准指南”，CJ Date，Hugh Darwen-Addison-Wesley），您需要书籍。
我不明白ANSI SQL的历史。 但似乎很多时候在软件开发中，标准都是在主要玩家已经实现自己的专有版本之后才写出来的。 一旦企业以自己的方式进行投资，就很难certificate改变或移除人们为了遵守标准而依赖的function是合理的。 Web标准是这种现象的主要例子。
Mimer SQL有很好的标准支持，但它还是个未知数。 它在几个大型厂址生产，大部分在瑞典。 但我认为很多网站正在迁移到其他网站。
详细的支持声明：
- SQL-99
- SQL-2003
- PSM
- 数据库触发器和函数根据SQL：1999
- 二进制和字符大对象（BLOB / CLOB / NCLOB）支持根据SQL：1999
- 多数据库事务（两阶段提交）符合Open Group的XA标准
- 支持Java ME CDC Foundation Profile和Java ME CLDC / MIDP
几年前，pipe道和连接器相互兼容的最差的行业之一就是消防设备。 有几十个相互不兼容的软pipe泵连接。 当消防员之间互助成为司空见惯的时候，他们不得不带上几十个适配器来互相配合。
9月11日，警方和消防员都有专门的无线networking，可以在他们之间进行交stream。 但猜猜怎么了？ 这两个系统不相容。 因此，从一种公共安全仆人到另一种公共安全人员的信息交stream不必要的拖延。
如果你走得够远，你可以在纽约市find一个时间，约有一半的电网是DC，受到爱迪生的青睐，另一半是AC，受到西屋公司的青睐。
标准有时是自发的，被称为事实标准。 更为普遍的是，标准必须由专门授权实现的机构来阐明。 对于SQL标准，一些最大的供应商预先标准。 为了符合标准，他们将不得不投入不利于他们现有客户群的工程费用。 更糟糕的是，他们最终可能会与先前的产品不兼容。
完全符合SQL标准可能会发生，但这不太可能。 即使这样做，新SQL标准的发展和遵从之间也有一段延迟时间。
恕我直言，数据库供应商推动ANSI SQL标准，在其领域内包含新特性和构造，而不仅仅是告诉数据库供应商“一个真正的方式”。
数据库市场由function，可扩展性和成本驱动。 通过等待ANSI批准语法来放弃和延迟技术优势（即分区，枢轴，UPSERT，复制）不是商业优先事项。 到此为止，已经有了专有语法的重要安装。
这就是说，在过去的几年中，大多数数据库供应商已经大大改善了他们对核心“ANSI SQL”的支持。 （使用SELECT FROM INFORMATION_SCHEMA和Oracle的ANSI连接的SQL Server实际上和CBO下的本地连接一样工作）
根据HSQLDB手册， 它是最符合标准的RDBMS 。
- 几乎所有SQL-92的语法特征都支持高级
- SQL：2008核心和这个标准的许多可选function
真正的原因是：大多数“开发者”是以客户为中心的编码者，因此既不理解也不关心科德博士的12条规则。 这也是为什么在webKiddie开发中频繁出现的MySql，它不是一个关系数据库。 这样的开发人员只需要简单的SELECT，UPDATE，DELETEparsing。 他们避免任何forms的限制，宁愿“在应用程序中执行”。 反动的1960年代的应用是你得到的。
他们中的大部分都非常合规。 但是这里有个坏消息，国际海事组织标准滋生了平庸。 供应商希望你能够locking到他们的扩展中，而且对非标准的事情通常有很好的理由。 实际上，您有多大可能将Oracle转储到SQL Server，反之亦然？ 除非你build立了一个你可以用来对付其他数据库的产品，否则你作为一个企业不太可能换掉数据库。 太痛苦了。
公司通常倾向于使用一个供应商来避免拥有不同的，可能不兼容的系统的丛林来支持。 培训开发人员/系统工程师使用一个数据库供应商的工具要比使用三种不同的工具要便宜得多。 之后，这家公司可能会增长到足以购买一些竞争对手。 这意味着你需要pipe理，集成等另一套完全不同的工具。
这是很多工作。
想象一下，相反，你有一个可移植性层，所以你真的不在乎下面的东西。 那会好很多。
这是一个经典的 – 这是答案。
如果你的SQL实现不符合ANSI标准，没有人会死亡，而如果没有遵循标准，人们可能会在炼油厂死亡。
