如何编写独立于数据库的应用程序?

要将数据库引擎与应用程序分离,请使用数据库抽象层(同时 data access layer ,或DAL)。您没有提到您使用的语言,但是所有主要语言都有很好的数据库抽象库。

但是,通过避免特定于数据库的优化,您将错过特定品牌的优势。我通常会抽象出可能的东西并使用可用的东西。更改数据库引擎是一个重要的决定,并且不会经常发生,最好使用最大程度上可用的工具。

您可以使用许多对象/关系映射器工具中的一个,比如hibernate/nhibernate、llblgen等等。这会给数据库的可移植性带来很大的帮助。无论您做什么,您都需要在模型和其他代码之间有一些抽象层。这并不意味着你需要某种依赖注入基础设施,但是良好的OO设计可以让你走得很远。此外,坚持简单的SQL,并认为这将使您具有可移植性是相当幼稚的。如果您的应用程序很琐碎,并且只使用非常琐碎的查询,那么这是正确的。

至于 总是 将应用程序编写为“任何数据库就绪”,我通常使用某种抽象层,这样就不难从一个数据库系统迁移到另一个数据库系统。但是,在许多情况下,这不是必需的,您是为Oracle平台、SQL Server或MySQL开发的,所以您不应该为了实现完全无缝的转换而牺牲所选RDBMS的好处。然而,如果您构建了一个好的抽象层,即使是针对特定的RDBMS,也不一定很难迁移到不同的RDBMS。

告诉你老板管好自己的事。不,当然不能对老板说这样的话,但要注意听好。

有趣的是,这个需求应该支持什么样的业务价值。一个明显的候选者似乎是数据库代码应该准备好在其他数据库引擎上工作,而不是当前的。如果是这样的话,那么这就是需求中应该说明的内容。

从那里开始,作为一名工程师,你需要找出实现这一目标的不同方法。其中一个可能是在编写ansi-sql。一种可能是使用数据库抽象层。

此外,你有责任告知你的老板不同替代方案的成本(在性能、开发速度等方面)。

“写入ansi-sql”…啊!

只是为了记录。StackOverflow上有一个类似的问题:

Database design for database-agnostic applications

100%兼容ANSISQL是一个很难实现的目标,但无论如何它也不能保证可移植性。所以这是人为的目标。

假设你的老板要求这样做是为了方便和快速地为将来的某些假设目的(实际上可能永远不会实现)切换数据库品牌。但他现在把未来的效率换成了更大的工作量,因为要使代码数据库保持中立很难。 ^*

所以如果你能用你的经理的目标来描述这个问题 应该 专注于像按时完成当前项目阶段和预算一样,这可能比告诉他让代码数据库中立太难更有效。

当您需要真正使数据库中立的代码时,也就是说,当您开发一个收缩包装应用程序时,需要支持多个品牌的数据库。

不管怎样,即使您目前只支持一个品牌,在某些情况下,您当然可以选择使用专有功能编写一些SQL代码,但也存在一种更为可移植的方法来实现相同的结果。您可以将这些视为“低挂起的水果”情况,并且如果需要,您可以在将来更容易地移植代码。但也不要限制自己,如果有价值的话,使用专有的解决方案。也许在注释中添加一个注释,说明如果/当您需要创建端口时,应该对其进行检查。

^* 在谈论平台独立性时,我更喜欢“中立”而不是“不可知论”。它避免了宗教色彩。-)