适用于 JavaScript 访问的 Android 数据库存储格式

Question

我正在开发一个 Android 应用程序，通常由用户填充一个相当小的数据库（数百到一千左右的主要条目，加上连接表中的类似数量级）。还有一个与每个主要条目相关联的文件，但它们是分开的，不属于这个问题的一部分。

在我当前的原型中，结构化数据以通常的方式存储在 SQLite 数据库中，并通过将文件上传到 Google Drive 上的应用程序文件夹在设备之间同步。这让我不必提供任何用户存储空间，这是我希望坚持的。

在此处存储文件还有一个令人愉快的副作用，即我可以使用 Google Drive API 通过网页中的 JavaScript 代码访问它们。但是 JavaScript 与远程 SQLite 文件交互是一件非常丑陋的尝试。 （下载数据库服务器端并处理它还有另一个选项听起来也不是很好。）我想知道是否有人对这里的最佳实践方法有任何建议，因为我想要一个基于 Web 的应用程序版本访问相同的数据。

显而易见的最明智的想法似乎是

首先从 SQLite 导出到其他结构化格式 XXX（如 XML、JSON、CSV 等），然后将该 XXX 文件上传到 Google Drive，这样JavaScript 可以直接与之交互，然后在同步时将此 XXX 数据重新导入 SQLite。

虽然我很高兴听到对此想法的任何批评/改进。

我主要对解决这些问题的有效方法的最佳实践建议感兴趣。问题：什么文件格式XXX比较好；您是否有任何推荐的方法来 (a) 在 Java 中从 SQLite 导出和导入到 XXX，(b) 最好在客户端 JavaScript 中与格式为 XXX 的远程 Google Drive 文件交互？ strong>（如果维护服务器端代码以与 XXX 交互是更好的做法，请说。）

Answer 1

这取决于您的应用将管理多少客户

首先从 SQLite 导出到其他结构化格式 XXX（如 XML、JSON、CSV 等），将该 XXX 文件上传到 Google Drive，以便 JavaScript 可以直接与之交互，然后同步重新导入此 XXX数据返回 SQLite。

恕我直言，这是一个非常糟糕的主意，原因有很多：

1. 如果多个用户同时尝试更改数据，那么管理所有这些数据条目和可能的冲突将会遇到困难
2. 提供对数据层的直接访问总是一个坏主意，因为任何客户端都可以清除您的所有数据

如果您的用户很少或将其作为个人项目，您可以坚持使用 SQLite。

Emscripten（C/C++ 到 Javascript LLVM 编译器）的开发者 Kripken 已将 SQLite 库编译为 Javascript 以制作 sql.js 库。您可以在GitHub 上找到它。还有一个demo page of sql.js

但如果您有很多用户，您可能希望使用Firebase by Google。它为您提供了一个数据库和一个 REST API 来使用它。还有libraries to access Firebase from different programming languages。

干杯！