SQL可移植性有多重要？

Question

在我看来，从个人经验和SO问题和答案来看，SQL实现差异很大。 SQL问题的首要问题之一是：您使用的是什么dbms？

在大多数使用SQL的情况下，有几种方法可以构建给定的查询，即使使用相同的方言也是如此。但我觉得有趣的是，各种方法的相对可移植性经常没有被讨论，也没有被高度重视。

但即使不考虑任何特定应用程序是否可能被转换，我认为我们希望我们的技能，习惯和模式尽可能便携。

在使用SQL时，您更倾向于使用标准SQL语法吗？您如何积极地避免礼仪变化？请在不参考专有偏好的情况下回答，以达到更好的表现，大多数人会承认这通常是足够合法的辩护。

Answer 1

我投票反对标准/供应商独立的sql

• 实际上很少切换数据库。
• 没有一个数据库完全符合当前的sql标准。因此，即使您符合标准，您也不是独立于供应商的。
• 供应商差异超越了sql语法。锁定行为是不同的。隔离级别不同。
• 数据库测试非常困难并且正在开发中。如果你不是绝对需要它，就不需要通过在游戏中投掷多个供应商来使其变得更加困难。
• 供应商特定调整中有很多功能。 （想想'限制'，或'分析功能'，或'提示'）

所以精华： - 如果不要求供应商独立，请专门针对您实际使用的供应商。 - 如果要求供应商独立，请确保谁支付账单，这将花费金钱。确保每个rdbms都可用于测试。并使用它 - 将每一段sql放在一个可插拔的特殊层中，这样你就可以使用数据库的强大功能并与不同的供应商合作 - 只有在差异是纯语法问题的情况下才符合标准，例如：使用oracle表示法（外部）连接与ANSI标准语法。

Answer 2

我们非常认真地对待我们的商店。我们不允许非标准SQL或扩展，除非它们在所有主要平台上都受支持。即便如此，它们在代码中被标记为非标准，并且必须提供理由。

应用程序开发人员无法快速运行查询，我们可以明确分离职责。该查询仅由DBMS本身或DBMS的DBA调优进行优化。

真正的数据库，比如DB2 / z :-)，可以快速处理标准SQL。

我们强制执行此操作的原因是为客户提供选择。他们不喜欢被锁定在特定供应商的想法，而不是我们。

Answer 3

根据我的经验，查询可移植性并不是那么重要。我们使用各种数据源（主要是MSSQL和MySQL），但我们知道哪些数据存储在哪里并可以相应地进行优化。由于我们控制系统，我们决定何时 - 如果有的话 - 移动结构并且需要重写查询。

我还想使用某些其他特定于服务器的功能，例如SQL Server中的查询通知，MySQL不提供。所以，我们再次使用它，并且不用担心可移植性。

此外，我们的部分应用需要查询架构信息并对其进行操作。在这里，我们再次为不同的系统提供服务器特定的代码，而不是试图将自己限制在最低的公分母。

Answer 4

没有明确的答案SQL可移植性是否可取 - 它实际上很大程度上取决于情况，例如应用程序的类型。

如果应用程序将成为一项服务 - 也就是说只有你托管它，那么很明显没人会，但你会关心你的SQL是否足够便携，所以你可以安全地忽略它，只要你没有特定的计划放弃对当前平台的支持。

如果要在多个站点上安装应用程序，每个站点都有自己建立的数据库系统，那么显然SQL可移植性对人们来说非常重要。它可以让您扩大您的潜在市场，并可能为那些在数据库系统方面处于困境的客户提供一些思路。例如，无论您是想要支持，还是仅仅向Oracle客户或仅向MySQL / PostgreSQL客户销售，都取决于您以及您对市场的看法。

如果您使用PHP进行编码，那么绝大多数潜在客户可能都会期待MySQL。如果是这样，那么假设MySQL并不是什么大不了的事。或者类似地，如果您在C＃/ .NET中，那么您可以假设Microsoft SQL Server。然而，还有另一个方面，因为可能存在一个小而竞争力较弱的PHP或.NET用户市场，他们希望连接到其他数据库系统而不是通常的。

所以我基本上认为这是一个市场研究问题，除非在我的第一个例子中提供托管服务，这对用户无关紧要，在这种情况下，它只是为了您自己的方便。