编写可移植 SQL 的必要性或便利性如何？

Question

我一次又一次地看到这里和其他地方的人们主张避免 SQL 语言的不可移植扩展， 这 就是最新的例子。我记得只有一篇文章阐述了我要说的内容，并且我不再有该链接了。

您是否真的从编写可移植 SQL 并放弃您方言的专有工具/语法中受益？

我从未见过有人煞费苦心地在 mysql 上构建一个复杂的应用程序，然后说 你知道什么是桃色吗？让我们切换到 (PostGreSQL|Oracle|SQL Server)！

PHP 中的通用库确实抽象了 SQL 的复杂性，但代价是什么？您最终将无法使用高效的构造和函数，因为您很可能永远不会使用假定的可移植性。对我来说，这听起来像是教科书《YAGNI》。

编辑： 也许我提到的例子太尖刻了，但我认为重点仍然是：如果您计划从一种 DBMS 迁移到另一种 DBMS，那么您可能无论如何都会重新设计应用程序，或者根本不会这样做。

Answer 1

与大型企业打交道的软件供应商可能别无选择（实际上这就是我的世界） - 他们的客户可能只有一个数据库供应商的产品使用政策。错过主要客户是商业上的困难。

当您在企业中工作时，您可以从该平台的知识中受益。

一般来说，DB层应该被很好地封装，所以即使你必须移植到一个新的数据库，这个改变也不应该是普遍存在的。我认为采用YAGNI方法进行移植是合理的，除非您有针对即时多供应商支持的具体要求。使其适用于您当前的目标数据库，但要仔细构造代码以实现未来的可移植性。

Answer 2

扩展的问题在于，在更新数据库系统本身时需要更新它们。开发人员通常认为他们的代码将永远存在，但大多数代码需要在5到10年内重写。数据库比大多数应用程序的存活时间更长，因为管理员足够智能，无法修复未破坏的内容，因此他们通常不会在每个新版本中升级系统。
但是，升级数据库时真的很痛苦对于较新的版本，扩展程序与该扩展程序不兼容，因此无法使用。它使升级变得更加复杂，并且需要重写更多的代码。
当你选择一个数据库系统时，你经常会坚持这个决定多年。
当你选择一个数据库和一些扩展时，你我坚持这个决定的时间要长得多！

Answer 3

我认为必要的唯一情况是，当您创建软件时，客户端将在自己的系统上购买和使用。到目前为止，大多数编程都不属于这一类。拒绝使用特定于供应商的代码是为了确保您拥有一个执行良好的数据库，因为通常编写特定于供应商的代码以提高某些任务的性能而不是ANSII标准SQL，并且编写该代码以优先考虑该数据库的特定体系结构。我已经使用数据库超过30年，从未见过公司在没有完整的应用程序重写的情况下更改后端数据库。在这种情况下，避免使用特定于供应商的代码意味着您在大多数情况下无缘无故地损害您的性能。

多年来，我还使用了许多不同的商业产品和数据库后端。毫无例外地，它们中的每一个都是为了支持多个后端而编写的，毫无例外地，它们中的每一个都是一个实际上每天使用的程序的悲惨，缓慢的狗。

Answer 4

在绝大多数应用程序中，我敢打赌，尝试编写可移植的sql几乎没有任何好处甚至是负面影响;但是，在某些情况下，有一个真实的用例。我们假设您正在构建时间跟踪Web应用程序。而且您想提供自托管解决方案。

在这种情况下，您的客户端需要拥有数据库服务器。你有一些选择。您可以强制他们使用可能限制您的客户群的特定版本。如果您可以支持多个DBMS，那么您可以使用更广泛的潜在客户端来使用您的Web应用程序。

Answer 5

• 如果您是公司，那么您可以使用为您提供的平台
• 如果您是供应商，则必须规划多个平台

企业的长寿：

• 在迁移 DBMS 之前您可能会重写客户端代码
• DBMS 可能会比您的客户端代码（针对 '80 大型机的 Java 或 c#）寿命更长

记住：

平台内的 SQL 通常是向后兼容的，但客户端库则不然。如果操作系统不支持旧的库、安全环境、驱动程序架构或 16 位库等，您将被迫迁移

因此，假设您在 SQL Server 6.5 上有一个应用程序。经过一些调整，它仍然可以在 SQL Server 2008 上运行。我敢打赌你没有使用正常的客户端代码......

Answer 6

使用“最低公分母”总是有一些好处和一些成本。一种语言的方言，以保障便携性。我认为，与编程语言，对象和函数库，报告编写者等类似的危险相比，锁定特定DBMS的危险性很低。

我建议这是保护未来可移植性的主要方式。创建包含表，列，约束和域的模式的逻辑模型。在SQL数据库的上下文中，尽可能使其独立于DBMS。关于唯一依赖于方言的东西是几个域的数据类型和大小。一些较老的方言缺乏域支持，但无论如何你应该根据域建立你的逻辑模型。从同一个域中抽取两列并且不仅仅共享一个通用数据类型和大小这一事实在逻辑建模中至关重要。

如果您不理解逻辑建模和物理建模之间的区别，请学习它。

尽可能多地使索引结构可移植。虽然每个DBMS都有自己的特殊索引功能，但索引，表和列之间的关系与DBMS无关。

就应用程序中的CRUD SQL处理而言，必要时使用DBMS特定的构造，但要尽量记录它们。作为一个例子，我毫不犹豫地使用Oracle的“CONNECT BY”。每当我认为它会对我有所帮助时就会构建。如果您的逻辑建模与DBMS无关，那么即使您没有太多努力，您的大部分CRUD SQL也将独立于DBMS。

到了移动的时候，期待一些障碍，但期望以系统的方式克服它们。

（上面的“你”一词是指它可能关注的人，而不是特别是OP。）