将SQL Server数据库设置为仅允许符合ANSI标准的SQL代码

有没有一种方法可以强制我的sql server数据库只使用符合sql的代码

通过这种方式，SQL代码很容易传输到其他数据库系统，如Oracle、IBM和其他符合ANSI标准的系统

或者其他可行的方法来获得同样的结果？

不，不是真的

然而，这并没有多大区别——在不同的SQL引擎中使用相同（ANSI或其他）的SQL只是一种错觉。现在通常的方法是使用为您构建查询的人——至少这允许在发送SQL之前进行一些优化。如果这很重要，您甚至可以拥有不同的数据库结构

即使数据类型及其表示形式在不同的数据库客户端之间也可能有所不同。例如，现在我正在开发一个使用数据集的传统Oracle应用程序。在Oracle上，所有的

number

s都是C#中的

decimal

s。在MS SQL中，一些是

decimal

s，一些是

int

s。即使使用纯ANSI SQL，您也需要处理像这样的微小不兼容，并且很难追求性能

例如，遗留应用程序中的一些Oracle查询使用显式索引-这确实是必要的，这要感谢（糟糕的）查询的构建和形成方式，但仅在Oracle上-MS SQL似乎根本不需要它们。MS SQL execution planner比Oracle SQL更好地处理SQL，反之亦然——两个引擎上的一些性能关键查询看起来完全不同。如果我能为每一个都有不同的DB结构，这将对性能有很大帮助。还有不同的开发模式-Oracle代码在插入之前请求ID（等等），而MS SQL上的标准是让DB引擎处理这个问题-您只需确保代码端的关联正确地转换到DB端的关系字段

这只是两个主要的DB引擎。MySQL、Postgres、DB2。。。即使在全ANSI模式下，它们都有一些小小的怪癖。此外，美国国家标准协会（ANSI）的标准甚至没有在这些标准中得到充分实施，泡沫很容易破灭

---

即使使用中间层（如某些O/RM系统），也会暴露大量泄漏。关键是要尽可能远离任何特定的东西，并确保每个人都清楚哪些地方你跟不上字谜游戏。

有人应该首先定义“符合ANSI标准”的含义以及我们谈论的符合性级别。没有数据库在所有一致性级别上都完全符合，即使是SQL92标准，我同意第一行。然而，我建议，任何不以符合标准的方式实现“SQL:86”或ANSI SQL的引擎都不能真正称为SQL引擎。@Jodrell当然。但这只是整个画面的一小部分。仅仅理解语法并在没有歧义的情况下应用它是很容易的部分（即使不是100%）。确保它真的工作正常，这是最困难的部分。ANSI SQL很好，但只是在一些小事情上，如使

case

在MS SQL和Oracle上工作相同，这样您就不必将

decode

转换为

case

等。这并不意味着您可以为所有数据库编写相同的SQL。抽象总是会泄露。ANSI SQL有很多漏洞：D@Jodrell2008年，ORDER BY成为合法订单，但所有产品都支持它，因为。。。嗯，我不记得那么远了。所有主要数据库都在某一点上使用了非标准扩展。我敢肯定，如果您检查SQL86，您会发现所有的异常，除非SQL86被取代，使最常见的扩展合法化。@PanagiotisKanavos

order by

无处不在，没错。但它在任何地方的效果也略有不同。当然，不是在最简单的查询中。但是添加子查询、分组、联合、窗口功能。。。它们都有各自的小差异，没有符合ANSI标准的SQL代码。各种标准（SQL92、99200320062082011）都有一致性级别，没有数据库完全符合所有这些标准。事实上，你提到的系统是一些最严重的违规者。你试图解决的真正问题是什么？如果修改默认值，会导致非标准行为，例如将ANSI_NULLS设置为off。在其他情况下，这些标准（有意地）不够模糊，以至于供应商可以实现他们想要的任何东西want@PanagiotisKanavos我正在构建由前端应用程序触发的soome SQL存储过程。但是，我希望这些存储过程是通用的，以便它们可以在各种rdbms上运行，而无需更改。这将是一个理想的场景。然后你看到了错误的技术。存储过程是标准化程度最低的。你提到的每种产品都有自己的特点。为什么要寻找通用过程而不是使用ORM？我有两个原因，其中只有一个是有效的。我不熟悉ORM。其次，逻辑将比CRUD操作更复杂，并且也将在大型数据集上。我认为SQL代码在DB引擎上比ORM更强大。谢谢你的意见。