与特定的 RDBMS API 相比，ODBC 有哪些优势？
我相信 ODBC 已经达到了在数据库引擎和操作系统上都更加可靠和可移植的程度。 如果考虑使用直接 RDBMS API，则没有太多速度优化的机会。
此外，ODBC 抽象确实使源代码更加可移植，因此迁移到新的 RDBMS 不需要完全重写代码！
然而，使用直接 API 可以通过删除抽象层来执行 ODBC，并且特定的 RDBMS 低级约束可以提供对特定 RDBMS 完整功能的访问。
你觉得这怎么样 ？
I believe ODBC has gotten to a point that it is more reliable and portable across both database engines and operating systems. There aren't too many opportunities for speed optimization if one should consider using a direct RDBMS API.
Also, ODBC abstraction, does make source code more portable so that migrating to a new RDBMS won't require complete code rewrite!
Nevertheless, using a direct API can out perform ODBC by removing layers of abstraction, and the specific RDBMS low level constraints can provide access to specific RDBMS full features.
What do you think of this ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通过 ODBC 发送的查询并不是真正可移植的，除非您使用可怕的 ODBC 转义序列。 即使这样，“可移植”部分也只是 SQL 语法的一小部分（例如，没有 DDL）。
坦率地说，我从未见过任何项目在这方面取得成功。 它们最多支持一组经过测试的驱动程序，例如 SQL/Oracle/DB2，仅此而已。 更好的方法是抽象您的应用程序数据访问层，并为您支持的每个后端提供不同的实现。
The queries sent through ODBC are not truly portable unless you use the dreaded ODBC Escape Sequences. Even then, the 'portable' part is only a small subset of the SQL grammar (eg. no DDL).
Frankly, I never seen a project succeed at this. At best they support a set of tested drivers, like SQL/Oracle/DB2 and that's it. A much better approach is to abstract your application data access layer and provide a different implementation for each back-end you support.
我认为使用 ORM 框架（例如 Hibernate 等）你会获得更好的整体灵活性（取决于编程环境）...
I think you would get better overall flexibility in using ORM framework, like Hibernate or such (depending on the programming environment)...