29

有人可以回答我的困境，使用哪种方法将Android设备连接到 mySQL 或 Postgresql？

我可以通过两种方式做到这一点，没有任何错误和问题，没有明显的区别，但每个人都推荐使用 Web 服务而不是使用 jdbc 驱动程序和直接连接，

有人可以用一些事实解释为什么吗？

编辑：我没有提到它更简单，并且需要更少的时间来完成 jdbc。那么，为什么是 Web 服务，或者为什么不呢？

4

5 回答 5

33

您认为使用 JDBC 更简单、更快捷，因为您没有考虑手机和便携式设备的真实操作环境。他们经常通过错误的流量重写代理和疯狂的防火墙来实现脆弱的连接。他们通常使用网络传输层，该层具有高且可变的丢包率和延迟，在短时间内变化多个数量级。TCP 在这种环境中确实不是很好，尤其是与长期连接的斗争。

Web 服务的主要优势在于：

  • 具有最小状态的短时连接，因此当设备切换 WiFi 网络、与蜂窝网络、短暂失去连接等时，很容易回到您所在的位置；和

  • 可以通过除最可怕和最严苛的网络代理之外的所有网络代理

您经常会遇到直接 JDBC 连接的问题。一个挑战是可靠地使死连接超时，重新建立会话并释放旧会话持有的锁（因为服务器可能不会在客户端决定它死的同时）。另一个是数据包丢失导致操作非常缓慢、长时间运行的数据库事务，以及随之而来的锁定持续时间和事务清理任务的问题。您还将在阳光下遇到各种疯狂和损坏的代理和防火墙 - 支持的代理CONNECT但后来假设所有流量都是 HTTP，如果不是，则将其破坏；带有错误状态连接跟踪的防火墙，导致连接失败或进入半开僵尸状态；你能想象到的每一个 NAT 问题；运营商“有用地”生成 TCP ACK 以减少延迟，更不用说丢包发现和窗口大小导致的问题；古怪的端口阻塞；等等

因为每个人都使用 HTTP，所以您可以期望它能够工作——至少，比其他任何事情都更频繁。现在尤其如此，即使在移动 Web 应用程序中，普通网站也使用 REST+JSON 通信方式。

您还可以使用唯一的请求令牌将您的 Web 服务调用编写为幂等的。这使您的应用程序可以重新发送修改请求，而不必担心它会对数据库执行两次操作。请参阅幂等性和定义幂等性。

说真的，来自移动设备的 JDBC 现在看起来可能是个好主意——但我什至会考虑的唯一方法是，如果移动设备都在我直接控制的单个高可靠 WiFi 网络上。即使这样，如果可能的话，出于数据库性能管理的原因，我也会避免使用它。您可以使用 PgBouncer 之类的东西在服务器端的许多设备之间建立连接池，因此连接池不是一个大问题，但是清理丢失和放弃的连接是，使其工作所需的 tcp keepalive 流量和长期停滞不前来自废弃连接的交易。

于 2013-04-06T16:58:01.737 回答
8

我能想到几个原因

  1. 为您的数据库提供 JDBC android 驱动程序支持。
  2. 跨各种 Android 设备的连接池使得监控和限制它们变得困难。
  3. 从 DB 发送到 android 的结果集会消耗大量带宽和电池电量。
  4. 代理通常允许 HTTP 访问您的设备。
  5. 将数据库直接暴露给客户端具有安全隐患。

Web 服务可以在 JDBC 连接之上提供附加功能，例如身份验证/服务质量/授权/条件 GET请求/错误处理等。JDBC 不能做任何这些。

于 2013-04-06T17:00:09.247 回答
6

除了 Craig Ringer 所说的（我完全同意）之外，JDBC 还有另一个问题：它会迫使您的数据库向世界公开。如果您希望 android 设备访问它，您需要为您的应用程序提供数据库凭据，并且数据库必须具有公共访问权限。

使用 WebService 或 RESTful API 显然是确保应用程序安全的方法。

于 2013-04-06T17:00:07.410 回答
0

另一种选择是使用像 SymmetricDS 这样的数据库同步工具。

这会让你在你的服务器上说一个 Postgres 数据库，在你的平板电脑上说一个 SQLite 数据库。

当连接可用时，SymmetricDS 将通过 HTTP 同步数据库。当然，您不必同步整个数据库，只需同步相关部分即可。

（我不隶属于 SymmetricDS）

于 2013-10-12T00:53:13.717 回答
-1

TL; DR：这取决于！ （对不起所有“从来没有做过，直接的骗子总是邪恶的”-开发者）

在为 Playstore 之类的东西创建公共领域/通用应用程序时，我主要与我的响应者同行。向“所有人”开放您的数据库（尤其是当权限配置错误或根本没有配置时）通常不是一个好主意！

但是（！），故事可能完全不同，例如，当您在公司的网络边界内创建一些供内部使用的东西时，例如用于物流、库存等的 Android 手持设备。在这些情况下，我什至大部分时间肯定会建议使用 JDBC 或类似的直接连接。原因是：

  • 少一个故障点
  • 少一个开发（子）项目
  • 少了一件需要维护和更新数据结构的事情
  • 少一件事要保持和运行，CI/CD，测试等（你得到草稿）

这 - 我的拙见 - 比连接池、重新建立等（如果它真的变得有必要，请小心那里的过早优化）的（实施一次）工作更糟糕。

但是对于公共项目......好吧，如果它们只需要读取访问权限，我也可以想象它，或者如果您只允许添加某些表，但不允许删除或修改。您可以应用一些技巧来使其仍然安全（允许添加但不允许使用特定表的 id-secrets 读取、触发器和其他表的一般读取等），但还有很多需要考虑和很多想念这些。所以一般来说，我会说让你的公共域客户端获取你的 SQL 连接是不好的做法。但是，不要让这妨碍您问自己（并理解）“为什么”并查看具体情况。甚至可能有很好的理由/用途。特别是因为它“少”，这通常也更好。这肯定取决于。

请注意并注意（即使权限设置正确）很多都可能被滥用（并且只有很少的阻碍），与您的客户端直接连接。（加上可能需要处理的连接问题。）

作为旁注：许多这些考虑因素再次与使用GraphQL等技术相关，它们有一些相似之处（但是没有连接问题并且具有更安全的控制）。

于 2021-10-20T09:05:04.800 回答