有人能回答我的难题吗？用哪种方法将Android设备连接到mySQL或Postgresql？
我可以用这两种方法都做到，没有任何错误和问题，没有明显的区别，但每个人都推荐使用web服务，而不是使用jdbc驱动程序和直接连接，
有人能用一些事实来解释为什么吗？
EDIT:我没有提到它更简单，通过jdbc完成它所需的时间更少.那么，为什么是web服务，或者为什么不是？
有人能回答我的难题吗？用哪种方法将Android设备连接到mySQL或Postgresql？
我可以用这两种方法都做到，没有任何错误和问题，没有明显的区别，但每个人都推荐使用web服务，而不是使用jdbc驱动程序和直接连接，
有人能用一些事实来解释为什么吗？
EDIT:我没有提到它更简单，通过jdbc完成它所需的时间更少.那么，为什么是web服务，或者为什么不是？
你可以看到，使用JDBC更简单、更快，因为你没有考虑手机和便携式设备的真实操作环境.它们通常通过有缺陷的流量重写代理和疯狂的防火墙实现脆弱的连接.他们通常使用的网络传输层具有高且可变的数据包丢失率和延迟，这些数据包丢失率和延迟在短时间内变化了许多数量级.在这种环境下，TCP真的不是很好，尤其是在长时间连接的情况下.
web服务的主要好处在于:
连接时间短，状态最低，因此当设备切换WiFi网络、与蜂窝网络之间切换、短暂失go 连接等时，很容易回到您的位置；和
除了最可怕、最严厉的网络代理之外，其他所有代理都可以通过
直接JDBC连接会遇到问题.一个挑战是可靠地对死掉的连接进行计时，重新建立会话，并释放旧会话持有的锁(因为服务器可能不会在客户端确定它死掉的同时确定它死掉).另一个是数据包丢失，导致操作非常缓慢，数据库事务长时间运行，以及锁持续时间和事务清理任务的后续问题.你还会遇到各种各样的疯狂的、坏掉的代理和sun下的防火墙——代理支持CONNECT个，但结果却认为所有流量都是HTTPs，如果不是的话，就把它弄坏；带有错误状态连接跟踪的防火墙，会导致连接失败或进入半开放僵尸状态；你能想象的每一个NAT问题；运营商"有益地"生成TCP ACK以减少延迟，更不用说丢包发现和窗口大小调整带来的问题；古怪的端口阻塞；等
因为everyone使用HTTP，所以你可以预期它会起作用——至少，比其他任何东西都要频繁得多.现在，即使在移动web应用程序中，普通网站也使用REST+JSON通信方式，这一点尤其正确.
您还可以使用唯一的请求令牌将web服务调用写入idempotent.这样，你的应用程序就可以重新发送修改请求，而不用担心会对数据库执行两次操作.见idempotence和definining idempotence.
说真的，移动设备的JDBC现在看起来是一个好主意——但我唯一能想到的是，如果移动设备在我的直接控制下都在一个高可靠的WiFi网络上.即便如此，出于数据库性能管理的考虑，如果可能的话，我也会避免使用它.您可以使用PgBouncer之类的工具在服务器端的多个设备之间共享连接，因此连接共享不是一个大问题，但清除丢失和放弃的连接是一个大问题，使其工作所需的tcp keepalive流量以及来自放弃的连接的长期停滞的事务也是一个大问题.