我的老板要求我只编写ANSI SQL以使其与数据库无关。但我了解到并不是那么容易，因为没有数据库完全兼容ANSI SQL。 SQL code can rarely be ported between database systems without modifications.
我看到人们以不同的方式使他们的程序数据库独立。例如：
您是否始终将代码编写为“任何数据库就绪”？或者只在需要时才这样做？ 如果是的话，你是如何实现的？
答案 0 :(得分：7)
您可以使用许多Object / Relational Mapper工具之一，如Hibernate / NHibernate，LLBLGen等。这可以让您在数据库可移植性方面走得很远。无论你做什么，你需要在你的模型和你的代码的其余部分之间有一些抽象层。这并不意味着您需要某种依赖注入基础架构，但良好的OO设计可以让您走得很远。此外，坚持使用简单的SQL并认为可以提高可移植性是相当幼稚的。如果您的应用程序是微不足道的，并且只使用非常简单的查询，那将是真的。
至于始终将应用程序编写为“任何数据库就绪”，我通常使用某种抽象层，因此从一个数据库系统移动到另一个数据库系统并不困难。但是，在许多情况下，这不是必需的，您正在为Oracle平台或SQL Server或MySQL开发，因此您不应仅仅为了完全无缝转换的可能性而牺牲所选RDBMS的优势。然而，如果您构建一个良好的抽象层，即使针对特定的RDBMS也不一定非常难以迁移到不同的RDBMS。
答案 1 :(得分：6)
要将数据库引擎与应用程序分离，请使用数据库抽象层（也是data access layer或DAL）。你没有提到你使用的语言，但是所有主要语言都有很好的数据库抽象库。
但是，通过避免特定于数据库的优化，您将错失特定品牌的优势。我通常抽象可能的东西并使用可用的东西。更改数据库引擎是一项重大决策，并不经常发生，最好使用最多可用的工具。
答案 2 :(得分：2)
告诉你的老板要记住他自己的事。不，当然一个人不能对老板说这些话，但请继续关注。
有趣的是这个要求应该支持什么样的商业价值。一个明显的候选者似乎是数据库代码应该准备好在当前的其他数据库引擎上工作。如果是这种情况，则应该在要求中说明。
从那以后，作为一名工程师，你需要找出实现这一目标的不同方法。一个人可能正在编写ANSI SQL。一个人可能正在使用数据库抽象层。
此外，您有责任告知您的老板不同替代方案的成本（在性能，开发速度等方面）。
“编写ANSI SQL”...... gah！
答案 3 :(得分：1)
仅供记录。 Stackoverflow上有一个类似的问题：
答案 4 :(得分：0)
100％符合ANSI SQL是一个难以实现的目标，但它无论如何都不能保证可移植性。所以这是一个人为的目标。
据推测，你的老板要求这样做，以便在未来（实际上可能永远不会出现）为了某些假设目的而轻松快捷地切换数据库品牌。但他现在正在将这种未来的效率换成更多的工作，因为使代码数据库中立更难。 *
因此，如果您可以根据您的经理应该关注的目标来解决问题，例如按时完成当前项目阶段和预算，则可能比告诉他更有效使代码数据库中立是非常困难的。
有一种情况需要制作真正与数据库无关的代码，即在开发支持多品牌数据库所需的收缩包装应用程序时。
无论如何，即使您目前只支持一个品牌，也有一些情况下您可以选择使用专有功能对某些SQL进行编码，但也存在一种更便携的方法来实现相同的结果。您可以将这些视为“低悬的水果”案例，如果需要，您可以在将来更轻松地移植代码。但是，不要限制自己，如果它们具有良好的价值，则使用专有解决方案。也许在评论中添加一个注释，如果/何时需要创建一个端口，这值得审查。
* 在谈论平台独立性时，我更喜欢“中性”这个词而不是“不可知论者”。它避免了宗教色彩。 ： - ）