我发现相同的查询在不同的 DBMS 中不起作用令人沮丧。
例如，某些 DBMS（例如 Microsoft SQL Server 和 MySQL）似乎支持该information_schema表，而其他DBMS（例如SQLite）则不支持。
一些数据库如 MySQL 允许你做SHOW TABLES，等等。
有些限制使用结果，SELECT TOP 10 ...而其他限制使用... LIMIT 10.
为什么不同的 DBMS 如此不兼容和异常？
他们为什么不遵循 SQL 标准？
哪些擅长坚持SQL标准？
哪些在遵守 SQL 标准方面是出了名的差？
Aar*_*and 15
我发现相同的查询在不同的 DBMS 中不起作用令人沮丧。
是的。我觉得令人沮丧的是，前灯和雨刷控制装置在不同的汽车中并不总是在同一个地方。因为我无法控制它，所以我学会了忍受它。我通常坚持使用某些汽车品牌，但这些东西的位置不在主要决策标准列表的顶部附近。同样，我不选择数据库平台，因为它们涵盖的标准百分比或多少查询与 Oracle 和 MySQL 中的工作方式相同。
例如，某些 DBMS（例如 Microsoft SQL Server 和 MySQL）似乎支持 information_schema 表，而其他 DBMS（例如 SQLite）则不支持。
INFORMATION_SCHEMA是一个有趣的选择。是的，一些平台选择根本不支持该标准。其他人已经涵盖了最低限度。我强烈反对INFORMATION_SCHEMA在 SQL Server中使用，例如：
一些数据库如 MySQL 允许你做 SHOW TABLES 等。
嗯，是的，有些数据库比其他数据库更臭名昭著，因为它们只是编造那些对当时代码中的开发人员来说似乎有意义的东西（LIMIT他们的反常GROUP BY宽恕是其他例子）。
为什么不同的 DBMS 如此不兼容和异常？
我相信有些人会做这样的事情，SHOW TABLES因为这被认为比SELECT name, other cols FROM sys.tables;. 事实上，我敢打赌这就是世界上大多数代码库的问题，包括 RDBMS；人们倾向于做更容易的事情而不是正确的事情。
但我不确定不同平台不兼容和你所说的“异常”是一个问题。
他们为什么不遵循 SQL 标准？
涵盖整个标准是困难的。覆盖仅标准更难。供应商开发标准的扩展，以及标准（尚未）涵盖的专有功能，为用户提供更强大的平台。想象一下，如果我们在开发任何东西之前坐下来等待标准的下一次迭代？想象一下，如果所有平台都覆盖了完整的标准，而只覆盖标准？想象一下，如果所有平台都只实现了他们都同意开发并同时发布的任何新功能？拥有不同平台有什么意义？它们都是一样的，不兼容将不再是一个问题，因为你可以在平台之间自由切换而没有风险——但如果它们都一样，你又何必呢？看看你正在“解决”的问题——它只是创造了一个不同的问题。
以索引为例。该标准不关心物理实现，一些供应商已经决定实现各种有益的索引变体和物理存储机制来改善他们的平台——SQL Server 过滤了索引，包括列、XML 索引、全文索引、内存表、列存储等。在标准中你不会读到其中的任何一个。因此，当他们开发这些东西时，他们应该如何使其与 Oracle 可能正在或可能未开发或计划的相同路线的任何内容兼容？Postgres 已经决定，详细的 JSON 支持远比并行处理带来的性能提升重要得多。这很好，完全在他们的权利范围内。这并不意味着我希望 SQL Server 做同样的事情。
对于跨平台的基本普通表，普通的临时 CRUD 内容应该相同（尽管即使在那里，MySQL 也做了一些时髦的事情，例如默认情况下在表名周围使用反引号，如果尝试将代码移植到任何其他平台，则需要将其去掉）。一旦你开始在标准存储和检索之外做任何更奇特的事情，标准就会向空中伸出双臂。你想要窗口函数吗？好的，您需要您的供应商卷起袖子并实施它们，因为大多数平台没有它们，并且它们需要大量工作；甚至 SQL Server 还没有完成，但他们已经领先于其他人。他们还有很多其他语言功能，我很高兴在那里，尽管它们不符合标准。
哪些擅长坚持SQL标准？
哪些在遵守 SQL 标准方面是出了名的差？
我对完整标准和所有评论平台的了解不够。但我会建议：如果这就是你选择一个或另一个平台的原因，停止你现在正在做的事情，问问自己为什么这如此重要。我还将建议 SQL Server 在遵守标准和实现有益的扩展方面做得更好（回顾历史，例如timestamp和，是的，top表明他们过去不太关心）。其他一些平台对标准竖中指，并继续这样做。