问题标签 [sql-standards]

DBMS 供应商使用 SQL 方言特性来区分他们的产品，同时声称支持 SQL 标准。'纳夫就此说道。

是否有任何您编写的无法转换为 SQL:2008 标准 SQL 的 SQL 示例？

具体来说，我说的是 DML（查询语句），而不是 DDL，存储过程语法或任何不是纯 SQL 语句的东西。

我也在谈论您将在生产中使用的查询，而不是临时的东西。

编辑 1 月 13 日

感谢您的所有回答：他们向我传达了一种印象，即创建了许多特定于 DBMS 的 SQL 以允许解决糟糕的关系设计。这使我得出结论，您可能不想移植大多数现有应用程序。

这一直困扰着我——为什么 SQL 语句中的 GROUP BY 子句要求我包含所有非聚合列？默认情况下应该包含这些列 - 一种“GROUP BY *” - 因为我什至无法运行查询，除非它们都被包含在内。每列必须是聚合或在“GROUP BY”中指定，但似乎任何未聚合的内容都应自动分组。

也许它是 ANSI-SQL 标准的一部分，但即便如此，我也不明白为什么。有人可以帮我理解这个公约的必要性吗？

Is there any way to test that SQL scripts contain standard SQL with java/junit tests?

Currently we have sql scripts for creating a database etc. in a Postgres db, but when using hsqldb everything fails. That's why I wonder if any java tools exist for testing if sql statements are standard sql.

Or would it just be wise to create different sets of scripts per database vendor? If so, is there a way to test if a given script works with postgres/hsqldb?

我们可以分类/说 TRUNCATE 属于/属于 DML 语句吗？

在此处查看PostgreSQL TRUNCATE 兼容性。

注意：TRUNCATE 是 SQL 标准 ANSI SQL 2008 - F200 的一部分

在过去的几年里，我遇到过一些开发人员认为 MySQL 不是 DBMS 的言论。我成为 MySQL 用户已经有一段时间了，我很难弄清楚为什么一些开发人员如此反对 MySQL。虽然我开始相信这些言论的一部分是正确的，但只是在很小程度上，我想知道为什么有些人仍然认为 MySQL 低劣的真正原因。

我同意我发现缺少检查约束，并且 BOOLEAN 约束到 TINYINT 范围内的 INTEGER 而不是 TRUE 和 FALSE。此外，还有一些我不喜欢的 CURRENT_TIMESTAMP 问题。但是，这些足以将 MySQL 吹捧为劣质 DBMS 的论据吗？这里的真正原因是什么——如果它们存在的话？

我很想知道有关各种 SQL 标准的更多详细信息，即SQL-92, SQL:99,SQL:2003等。 WikipediaSQL:2008上有一个简短而有用的概述，其中包含指向非常昂贵的文档的链接。为什么这些文件不向公众开放？我能找到一些开放和免费的信息吗？

请不要发布您从 Google 找到的链接。我只对有些权威的文档感兴趣。

在SQL:2008和以前的标准中，INFORMATION_SCHEMA被描述为标准元模式。原则上，可以将元数据卸载到 XML 中，以便使用 XSLT 和其他 XML 工具对模式元数据进行进一步处理和逆向工程。

• 以前有这样做过吗？
• 是否有一些完整的 XSD 可用，描述INFORMATION_SCHEMA?

注意：我问这个是因为我想在jooq-metaINFORMATION_SCHEMA中实现将数据库模式卸载到 SQL 标准XML 结构中，然后在第二个过程中再次加载该模式，以在 jOOQ 中生成 Java 源代码工件。为此，我不希望推出自己的 XSD，而是使用预先存在的尽可能接近标准的 XSD

我很好奇我是否可以依赖任何特定的验证NOT NULL, FOREIGN KEY, UNIQUE, CHECK约束和BEFORE触发器的顺序。

根据经验，我知道 MySQL 首先检查NOT NULL，然后启动BEFORE触发器，然后检查UNIQUE约束。Oracle在触发器NOT NULL之后进行检查BEFORE（我相信 SQLServer 也会这样做，但不记得了）。标准是否说明了订单或完全取决于数据库供应商？

In Postgres, ANY and SOME are synonyms when used on the right hand side of a predicate expression. For example, these are the same:

This is documented here:

http://www.postgresql.org/docs/9.1/static/functions-subquery.html#FUNCTIONS-SUBQUERY-ANY-SOME

I have observed ANY and SOME to be supported by at least these SQL DBMSs:

• DB2
• Derby
• H2
• HSQLDB
• Ingres
• MySQL
• Oracle
• Postgres
• SQL Server
• Sybase ASE
• Sybase SQL Anywhere

Can I safely assume that all of those dialects (and others, too) treat ANY and SOME as synonyms or is there a subtle difference between the two keywords in any/some DBMS?

I have found this in the SQL92 definition:

This doesn't say anything about the semantics of ANY and SOME. Later on in the document, only <some> is referenced, not the two keywords. I'm suspecting that there might be a subtle difference in NULL handling, for instance, at least in some DBMSs. Any/some pointer to a clear statement whether this can be assumed or not is welcome.

我完全理解为什么我必须有两个不同的条件背后的原因。令我困惑的是为什么这么多年后仍然没有一个标准的快捷表示法。

我可以看到为什么各种 dbms 实现不提供快捷方式，因为它不是必需的，这样做会使您的 sql 的可移植性大大降低，但是考虑到这种快捷方式在所有 dbms 中的有用性，我无法理解为什么权力尚未在 sql 规范中添加执行此操作的快捷方式。

我的问题：实际上是否有正当理由，如果有，那是什么？