在我看来，从个人经验和 SO 问题和答案来看，SQL 实现差异很大。 SQL 问题的首要问题之一是：您使用的是什么 dbms？
在使用 SQL 的大多数情况下，有多种方法可以构建给定的查询，即使使用相同的方言也是如此。但我发现有趣的是，各种方法的相对可移植性经常没有被讨论，也没有被高度重视。
但即使忽略任何给定应用程序可能会或不会进行转换的可能性，我认为我们更希望我们的技能、习惯和模式尽可能可移植。
在您使用 SQL 的过程中，您对标准 SQL 语法的偏好程度如何？你如何积极地避免适当的变化？请在回答时不参考专有偏好，以实现更好的性能，大多数人会承认这通常是一种足够合理的辩护。
【问题讨论】：
标签： sql portability
我投票反对标准/供应商独立的 sql
所以精髓： - 如果不需要供应商独立性，请针对您实际使用的供应商进行专业化。 - 如果需要供应商独立性，请确保谁来支付账单，这将花费金钱。确保每个 rdbms 都可用于测试。并且也使用它 - 将每条 sql 放在一个特殊的层中，这是可插拔的，因此您可以使用数据库的强大功能并与不同的供应商合作 - 仅当差异是纯粹的语法问题时才符合标准，例如对（外部）连接使用 oracle 表示法与 ANSI 标准语法。
【讨论】：
我们的商店非常重视这一点。我们不允许非标准 SQL 或扩展，除非它们在所有主要平台上都受支持。即使这样，它们在代码中也被标记为非标准，并且需要证明。
应用程序开发人员不能让他们的查询快速运行，我们有明确的职责分离。该查询只能由 DBMS 本身或 DBMS 的 DBA 调整来优化。
真正的数据库，如 DB2/z :-)，处理标准 SQL 的速度非常快。
我们强制执行此操作的原因是为客户提供选择。他们比我们更不喜欢被锁定在特定供应商的想法。
【讨论】：
根据我的经验，查询可移植性并不是那么重要。我们使用各种数据源（主要是 MSSQL 和 MySQL），但我们知道哪些数据存储在哪里，并且可以进行相应的优化。由于我们控制系统，因此我们决定何时移动结构以及何时需要重写查询。
我还喜欢使用某些其他特定于服务器的功能，例如 MySQL 不提供的 SQL Server 中的查询通知。因此，我们再次在可能的情况下使用它，而不用担心可移植性。
此外，我们的部分应用需要查询架构信息并对其采取行动。在这里，我们再次为不同系统提供特定于服务器的代码，而不是试图将自己限制在最低的公分母上。
【讨论】：
SQL 可移植性是否可取没有明确的答案 - 这在很大程度上取决于具体情况，例如应用程序的类型。
如果应用程序将成为一项服务 - 即只有您托管它，那么显然没有人会关心您的 SQL 是否足够便携，因此只要您没有特定的 SQL，您就可以放心地忽略它计划停止对您当前平台的支持。
如果应用程序要安装在多个站点，每个站点都有自己建立的数据库系统，显然 SQL 可移植性对人们来说非常重要。它可以让你拓宽你的潜在市场，并且可以让那些对他们的数据库系统持观望态度的客户放心。无论您是想支持这一点，还是只向 Oracle 客户销售产品，还是只向 MySQL/PostgreSQL 客户销售产品，这都取决于您和您认为的市场。
如果您使用 PHP 进行编码，那么绝大多数潜在客户可能会期待 MySQL。如果是这样，那么假设 MySQL 没什么大不了的。或者类似地，如果您使用 C#/.NET，那么您可以假设 Microsoft SQL Server。然而，同样存在另一面，因为 PHP 或 .NET 用户可能存在一个较小但竞争较弱的市场，这些用户希望连接到其他数据库系统，而不是通常。
因此，我主要将此视为一个市场研究问题，除非在我的第一个示例中，您提供的托管服务对用户无关紧要，在这种情况下，这只是为了您自己的方便。
【讨论】：