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