SQL可移植性有多重要？

Question

从我个人的经验和SO的问题和答案来看，SQL实现差别很大。对于SQL问题而言，首要问题之一是：您使用的是哪种dbms？

在大多数情况下，在使用相同的方言时，有几种方法可以构建给定的查询。但是我认为有趣的是，各种方法的相对可移植性通常不被讨论，也不被高度重视。

但是即使忽略任何应用程序可能需要转换的可能性，我认为我们应该尽可能地使我们的技能、习惯和模式具有可移植性。

在您处理SQL的工作中，您有多么喜欢标准的SQL语法？您有多么积极地避免使用专有变体？请回答而不涉及专有偏好，以达到认为更好的性能为目的，这通常是充分合理的辩护。

- le dorfier

Answer 1

我反对使用标准/供应商独立的SQL。

• 实际上很少切换数据库。
• 没有一个数据库完全符合当前的SQL标准。所以即使你符合标准，也不是供应商独立的。
• 供应商之间的差异不仅限于SQL语法。锁定行为不同，隔离级别也不同。
• 数据库测试非常困难且不够发展。如果不是绝对需要，就不要增加多个供应商，让测试变得更加困难。
• 供应商特定的调整有很大的作用。（比如'limit'、'analytic functions'、'hints'）

所以要点是：

• 如果没有对供应商独立性的要求，那就专注于你实际使用的供应商。
• 如果有对供应商独立性的要求，请确保支付账单的人明白，这将需要花费一些钱。确保你拥有每个可用于测试的关系型数据库，并加以使用。
• 将每个 SQL 语句放在一个特殊的层中，该层是可插拔的，这样你就可以同时利用数据库的强大功能并与不同的供应商合作。
• 只有在语法纯粹是一个问题的情况下才使用标准，例如使用 Oracle 的符号表示（外）连接，而不是 ANSI 标准的语法。

- Jens Schauder

---

第二个说法很勇敢，你的来源是什么？我给你投了一个反对票，如果你能证明或者撤回这个说法，我会很高兴地把它改成赞同（所以请不要无端报复）。我得到的可靠信息是DB2/z是严格符合标准的。 - paxdiablo

除非你的项目从一开始就明确声明并针对多个数据库，否则几乎不太可能进行切换 - 没有可移植性意义，我同意。 - marc_s

你读了这个问题吗？1. 我已经排除了数据库切换。2. 你认为汽车安全设备是无关紧要的，因为没有一辆车是防撞的吗？3. 非语法差异是一个转移注意力的话题。4. 我没有加入多个供应商。5. 我承认性能是一个合理的防御。 - dkretz

那么你的标准 SQL 代码提供了什么样的“安全性”？到目前为止，唯一支持标准的论点是：如果您需要独立于供应商，则可以节省维护多个版本的 SQL 代码的工作。但我没有看到其中任何安全性。 - Jens Schauder

我确实喜欢、欣赏和尊重DB2，但是HyperSQL更加符合规范。 - Blaine

Answer 2

我们非常重视这个问题。除非所有主要平台都支持，否则不允许使用非标准SQL或扩展。即使是被支持的，它们在代码中也会被标记为非标准，并且需要进行说明。

应用程序开发人员不能使他们的查询运行更快，我们有明确的职责分工。查询仅由DBMS本身或DBA调整DBMS进行优化。

像DB2 / z这样的真实数据库可以处理标准SQL。

我们强制执行此规定的原因是为了给客户选择的机会。他们不喜欢被锁定在特定的供应商那里，我们也是如此。

- Pax

---

有趣，我听说过像SAP这样的公司也有类似的事情。在SQL层面解决供应商独立性问题的原因是什么？ - Jens Schauder

不确定我是否完全理解问题，@Jens。如果您问为什么我们只执行标准SQL，那是为了方便在供应商（和平台）之间轻松切换。因此，当MySQL不再适用时，我们可以转移到SQL Server，然后是DB2 / LUW，最后是DB2 / z。所有这些都无需更改应用程序。 - paxdiablo

还有一个需要维护的层。如果您按照标准编码，就不需要它，并且可以根据需要转移到更适合的DBMS以提高性能。请记住，这是我们的做法，不一定是唯一（或正确）的方法，尽管我们相信是这样，否则我们就不会这样做。 - paxdiablo

“在代码中标记为非标准” - 是什么标记了代码？您使用哪个RDBMS和/或IDE？我需要一个工具来查找我们代码库中的非标准SQL。提前感谢。 - kol

@koi，开发人员会标记它，在代码检查期间进行检查，很抱歉，我们不使用工具来完成这项任务。 - paxdiablo

Answer 3

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

我还喜欢使用某些其他特定于服务器的功能，例如 SQL Server 中的查询通知，而 MySQL 不提供此功能。因此，在这种情况下，我们尽可能使用它，不必担心可移植性。

此外，我们的应用程序的某些部分需要查询模式信息并对其进行操作。同样，在这里，我们为不同的系统编写了特定于服务器的代码，而不是试图限制自己到最低公共分母。

- Tom Juergens

Answer 4

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

如果应用程序将成为一个服务 - 即只有您托管它，那么显然除了您以外，没有人会关心您的SQL是否足够可移植，因此只要您没有特定计划放弃对当前平台的支持，您可以安全地忽略它。

如果应用程序将安装在许多站点上，每个站点都有自己的数据库系统，那么SQL可移植性显然对人们非常重要。它可以扩大您的潜在市场，并可能给那些对其数据库系统犹豫不决的客户一些安心感。您是否想支持它，或者您是否愿意仅向Oracle客户或仅向MySQL / PostgreSQL客户出售，取决于您认为自己的市场是什么。

如果你在使用PHP编程，那么绝大多数潜在客户可能会期望MySQL。如果是这样，那么假设MySQL并不是什么大问题。同样地，如果你在使用C#/.NET，那么你可以假设Microsoft SQL Server。然而，有一个反面情况，因为可能存在一小部分PHP或.NET用户想要连接到其他非常规的数据库系统。

因此，我认为这主要是一个市场调研问题，除非像我第一个例子中提到的那样，你提供的是托管服务，对用户来说并不重要，那么这只是为了方便你自己。

- thomasrutter