编写可移植的SQL有多必要或方便?

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

当你工作时 在内部 您可以从平台知识中获益的企业。

一般来说,DB层应该被很好地封装,所以即使您必须移植到一个新的数据库,更改也不应该普及。我认为采用Yagni方法移植是合理的,除非您对立即多供应商支持有特定要求。使其与当前的目标数据库一起工作,但要仔细地构造代码,以便将来能够移植。

扩展的问题是,当您更新数据库系统本身时,需要更新它们。开发人员通常认为他们的代码将永远存在,但大多数代码需要在5到10年内重写。数据库的生存时间往往比大多数应用程序都长,因为管理员足够聪明,不会修复未损坏的内容,因此他们通常不会用每个新版本升级系统。
不过,当您将数据库升级到较新的版本,但扩展不兼容,因此无法工作时,这是一个真正的痛苦。这使得升级更加复杂,需要重写更多的代码。
当你选择一个数据库系统的时候,你通常会多年来一直坚持这个决定。
当你选择一个数据库和一些扩展时,你会在这个决定上停留很长时间!

我能看到的唯一必要的情况是,当您创建软件时,客户机将购买并在自己的系统上使用。到目前为止,大多数编程都不属于这一类。拒绝使用特定于供应商的代码是为了确保您有一个性能良好的数据库,因为通常编写特定于供应商的代码是为了提高某些任务在ANSII标准SQL上的性能,而编写该代码是为了宣传该数据库的特定架构。我已经与数据库合作了30多年,但我从未见过一家公司在没有完全重写应用程序的情况下更改其后端数据库。在这种情况下,避免使用特定于供应商的代码意味着大多数情况下,您没有任何理由会损害您的性能。

这些年来,我还使用了很多不同的商业产品和数据库后端。无一例外,他们中的每一个都是为支持多个后端而编写的,而且,无一例外,他们中的每一个都是一个每天实际使用的程序的可怜的、缓慢的狗。

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

在这种情况下,您的客户机将需要一个DB服务器。这里有一些选择。你可以强迫他们使用一个特定的版本来限制你的客户群。如果您可以支持多个DBMS,那么您就有了一个更广泛的潜在客户机,可以使用您的Web应用程序。

• 如果你是公司的,那么你就使用你得到的平台。
• 如果你是一个供应商,你必须计划多个平台

企业寿命:

• 在迁移DBMS之前,您可能会重写客户机代码。
• DBMS可能会超过客户端代码(Java或C’s’80主机)。

记得:

平台中的SQL通常是向后兼容的,但客户端库不是。如果操作系统不支持旧库、安全环境、驱动程序体系结构或16位库等,则必须迁移。

因此,假设您在SQL Server 6.5上有一个应用程序。它仍然在SQL Server 2008上运行,只是做了一些调整。我敢打赌你没有使用健全的客户端代码…

为了保证可移植性,使用一种语言的“最小公分母”方言总是有一些好处和成本。我认为,与编程语言、对象库和函数库、报告编写器等类似的危险相比,锁定到特定DBMS的危险很低。

以下是我建议的保护未来可移植性的主要方法。建立一个包含表、列、约束和域的架构逻辑模型。在SQL数据库的上下文中,使其尽可能独立于DBMS。唯一依赖方言的是一些域的数据类型和大小。一些旧的方言缺乏域支持,但无论如何,您应该根据域建立逻辑模型。事实上,两列是从同一个域中绘制的,并且不只是共享一个通用的数据类型和大小,这在逻辑建模中至关重要。

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

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

就应用程序中的CRUD SQL处理而言,在必要时使用DBMS特定的构造,但尽量将它们记录下来。例如,每当我认为Oracle的“connect by”结构对我有好处时,我都会毫不犹豫地使用它。如果您的逻辑建模是独立于DBMS的,那么即使您不费吹灰之力,大部分CRUD SQL也将是独立于DBMS的。

当需要移动的时候,期望一些障碍,但是期望以系统的方式克服它们。

(上文中的“你”一词是指它可能涉及的人,而不是具体的行动计划。)