我的老板要求我只编写 ANSI SQL 以使其独立于数据库。但我了解到这并不容易，因为没有完全兼容 ANSI SQL 的数据库。SQL 代码很少能在不修改的情况下在数据库系统之间移植。
我看到人们用不同的方式使他们的程序数据库独立。例如：
- 将 SQL 语句外部化为资源文件。
- 编写许多提供程序类来支持不同的数据库。
- 只写简单的 SQL，远离高级函数/连接。
您是否总是编写“任何数据库就绪”的代码？还是仅在需要时才这样做？如果是，你是如何实现的？
问问题
4159 次
5 回答
7
您可以使用众多对象/关系映射器工具之一，例如 Hibernate/NHibernate、LLBLGen 等。这可以让您在数据库可移植性方面走得更远。无论您做什么，都需要在模型和其余代码之间有一些抽象层。这并不意味着您需要某种依赖注入基础架构，但良好的 OO 设计可以让您走得更远。此外，坚持使用简单的 SQL 并认为可以为您带来可移植性是相当幼稚的。如果您的应用程序是微不足道的并且只使用非常微不足道的查询，那将是正确的。
至于总是将应用程序编写为“任何数据库就绪”，我通常使用某种抽象层，因此从一个数据库系统迁移到另一个数据库系统并不难。但是，在许多情况下，这不是必需的，您正在为 Oracle 平台或 SQL Server 或 MySQL 进行开发，因此您不应该为了完全无缝转换的可能性而牺牲您选择的 RDBMS 的好处。然而，如果您构建了一个好的抽象层，即使针对特定的 RDBMS 也不一定很难迁移到不同的 RDBMS。
于 2008-12-21T16:33:47.240 回答
6
要将数据库引擎与应用程序分离，请使用数据库抽象层（也称为数据访问层或 DAL）。你没有提到你使用什么语言，但是所有主要语言都有很好的数据库抽象库。
但是，通过避免特定于数据库的优化，您将错过特定品牌的优势。我通常抽象出可能的东西并使用可用的东西。更改数据库引擎是一项重大决策，并且不会经常发生，最好尽可能使用您可用的工具。
于 2008-12-21T16:35:41.997 回答
3
告诉你的老板管好自己的事。不，当然不能对老板说这样的话，但请继续关注。
有趣的是这个需求应该支持什么商业价值。一个明显的候选似乎是数据库代码应该准备好在除当前之外的其他数据库引擎上工作。如果是这种情况，那么这就是要求中应说明的内容。
作为一名工程师，您可以从那里找出实现这一目标的不同方法。一个人可能正在编写 ANSI SQL。一种可能是使用数据库抽象层。
此外，您有责任告知您的老板不同替代方案的成本（在性能、开发速度等方面）。
“编写 ANSI SQL”……呸！
于 2008-12-21T17:08:54.987 回答
1
只是为了记录。Stackoverflow 上有一个类似的问题：
于 2008-12-21T17:19:37.117 回答
1
100% 符合 ANSI SQL 是一个难以实现的目标，但无论如何也不能保证可移植性。所以这是一个人为的目标。
据推测，您的老板要求这样做是为了方便快捷地切换数据库品牌以用于将来的某些假设目的（实际上可能永远不会发生）。但是他现在正在用这种未来的效率来换取更多的工作，因为使代码与数据库无关变得更加困难。*
因此，如果您可以根据您的经理应该关注的目标来表述问题，例如按时并按预算完成当前的项目阶段，这可能比仅仅告诉他使代码与数据库无关太难更有效.
有一种情况是您需要编写真正与数据库无关的代码，即您正在开发一个需要支持多个品牌数据库的收缩包装应用程序。
无论如何，即使您目前只支持一个品牌，在某些情况下您肯定可以选择使用专有功能编写一些 SQL，但也存在一种更便携的方式来实现相同的结果。您可以将这些视为“唾手可得”的案例，并且可以在将来需要时更轻松地移植代码。但是也不要限制自己，如果它们提供良好的价值，请使用专有解决方案。如果/当您需要进行移植时，可能会在评论中添加注释，这值得审查。
*在谈论平台独立性时，我更喜欢“中立”这个词而不是“不可知论”这个词。它避免了宗教色彩。:-)
于 2008-12-21T22:13:57.537 回答