ODBC 与通过 Internet 进行数据库管理的较新方法
我正在承担一个遗留项目，其中数据库管理是使用 ODBC 连接通过互联网进行处理的。 遗留程序最近已用 C# 重写。 我们目前正在讨论如何改进程序，我对使用 ODBC 连接数据库有点不舒服。 我已经编写了使用套接字和 POST、PUT 和 GET 命令与 cgi 或 php 脚本相结合来连接到服务器的例程，并且广泛阅读了有关 AJAX 范例的内容，我认为这是前进的方向。 我的同事坚持使用ODBC。 与更现代的方法相比，使用 ODBC 连接有哪些优缺点？
I am taking on a legacy project in which database management was handled over the internet using an ODBC connection. The legacy program has recently been rewritten in C#. We are currently discussing how to improve the program and I am a bit uncomfortable with using ODBC to connect to the database. I have written routines to connect to a server using sockets and POST, PUT, and GET commands combined with cgi or php scripts and have read extensively about the AJAX paradigm which I see as the way forward. My colleague insists on using ODBC. What are the pros and cons of using an ODBC connection vs. a more modern approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
数据库到应用程序的协议从来就不是为了在互联网上使用而设计的。 他们太健谈而且很难保护。 如果您有机会这样做，那么您应该考虑将数据库封装在适当安全的 Web 服务后面。
Database-to-application protocols were never designed to be used over the internet. They are too chatty and difficult to secure. If you have the opportunity to do so, then you should consider encapsulating the database behind a properly-secured web service.
over ODBC 一点也不“现代”。 只需确保将其封装在 SSL 和/或 VPN 中并使用合理的访问控制即可。
它会比 HTTP 更高效，而 HTTP 并不是为此而设计的。 至少，HTTP 命令为每个操作增加了大量开销。 ODBC 将为您带来更好的延迟（这对于客户端驱动的数据库设计至关重要）
there's nothing 'modern' about HTTP over ODBC. just be sure to wrap it in SSL and/or a VPN and use sensible access controls.
it will be a lot more efficient than HTTP, which wasn't designed for this. at the very least, HTTP commands add a lot of overhead for each operation. ODBC will get you far better latency (which is critical in client-driven DB designs)
将 ODBC 与现代方法（Web 服务）结合使用怎么样？ 这种方法有很多优点。 例如：
访问数据。 没有必要
分别编写数据库相关代码
个人申请。
源仅在服务器计算机上
托管 Web 服务。 客户
程序可以在其他设备上运行
网络上的机器。
访问数据库必须做的就是调用
网络服务。
程序。
中心位置（网络服务）。
当然，查询的复杂性存在一些安全问题和限制。
How about using ODBC with a modern approach, web services. There are many advantages to this approach. For example:
access data. There is no need to
write database related code in each
individual application.
sources only on the server machine
that hosts the web service. Client
programs can be running on other
machines over the network.
have to do to access database is call
a web service.
programs.
central location (the web service).
Of course, there are some security issues and limitations to the complexity of your queries.
我的办公室里也有类似的东西。 他们有很多机器，其中的 VB.NET 应用程序访问本地数据库（经常会因为太多未使用的连接而陷入困境），以及一些通过 SSH/SSL 隧道联系外部数据库的 Web 服务。
我们的外部数据库并没有真正遇到很多问题，除非隧道发生故障，这种情况很少见。 您或许还可以设置 VPN。
如果您有兴趣使用 AJAX/JSON/REST 技术与数据库通信，您可以使用抽象层，例如 DBSlayer。
I had something similar in my office. They had lots of machines with VB.NET apps hitting the local database (regularly got it stuck with too many unused connections) and some web services that contacted an external database through an SSH/SSL tunnel.
We didn't really have a lot of problems with the external database unless the tunnel went down which was rare. You can probably also set up a VPN.
If you are interested in using AJAX/JSON/REST technologies to communicate with a database, you can use an abstraction layer like DBSlayer.
使用 TypeIV“直接”数据库驱动程序（例如 C# 的 System.Data.SqlClient 命名空间）或 Java 的 JDBC 驱动程序，比通过 ODBC 层的效率高 2-3 倍（更好的性能）。
我会避免使用 ODBC，因为它速度较慢，而且我认为它也并不容易。
Using a TypeIV "direct" database driver like the System.Data.SqlClient namespace for C# ,or a JDBC driver for Java, is 2-3 times more efficient (better performance) than going through the ODBC layer.
I would avoid ODBC because its slower and I think its not any easier.