更新本地Android数据库

基本思路

这就是我的做法。我在这里假设客户端应用程序不对本地数据库进行更改（下载新版本时除外），因此数据库中只有少数可能的版本存在（每次您使用一个在服务器端进行了更改）。

1. 将列添加到每个被调用的表中LastModified，默认值为NOW()。这意味着每次向主副本添加某些内容时，它将获得更新的LastModified设置。您将必须确保您的更新（而不是插入内容）也更改了该LastModified字段。
2. 在数据库中某个地方（Settings表或某物）中存储一个字段，该字段跟踪此版本的数据库在服务器上发布的日期（称为PublishDate）。
3. 当客户端要检查新版本时，它将其发送PublishDate到服务器。然后，服务器会检查每个表，发现所有行上LastModified后说到PublishDate。它将SQL发送到客户端以在客户端上插入或更新这些行。它还发送新消息，PublishDate以便客户端可以在其本地副本中进行更新。

这涉及插入和更新。它不处理删除。在您的情况下，这可能不是问题；如果他们是：

4. 将一个单独的表添加到日志删除中，并在其中跟踪LastModified，以便您可以告诉客户端要删除哪些行。或最好有一个设置，在该设置中您实际上从未删除任何行，而只是将它们更新为标记为“已删除”。

最后，这将无法处理架构更改。再次，希望这不是您的问题：希望您有一个稳定的架构。但是，如果您确实需要添加或删除表或索引之类的东西，则必须单独进行：

5. SchemaChanges在您的主数据库上创建一个表格，每当进行结构更改时，将相关的详细信息SchemaChanges以及LastModified日期一起放入表格中，以便您也可以根据要求将此内容发送给客户端。如果执行此操作，则需要先将架构更改发送给客户端，因为它们可能会影响其他更改的含义。

现在，以这种方式进行操作的好处是，您可以对服务器上的所有内容进行预处理（因为现有版本很少）。对于每个旧版本，您可以（基于上述详细信息）计算将旧版本升级为新版本的更改，然后将生成的SQL存储在服务器上。如果这样做，则避免了即时生成SQL的需求：当客户端发送时PublishDate，您只需查找已经计算出的SQL，即可将版本从PublishDate最新版本转换为最新版本。

替代实施

有一种很好而又容易的方法来推动上述方案为您带来的更改，即使稍作简化也不需要LastModified时间，甚至不需要对现有结构进行任何更改。在服务器端，您已经拥有旧版本（因为拥有所有旧版本）和新版本，您将创建两个数据库的SQL转储，然后对其运行diff以生成可发送到的补丁文件。客户端应用。客户端应用程序将使用相同的Java库来生成旧版本的SQL转储，然后对其应用diff修补程序以为新版本创建完整的SQL转储。此时，它可以删除旧数据库并从SQL转储中创建新数据库。

如果更改不是批量更改，这将非常有效（在这种情况下，您最好只推送新.db文件）。

通过调用SQLite二进制文件来创建转储是很容易做到的。根据执行外部命令的这种方式，您将需要稍微修改Android的方法。

您可以使用此Google库在服务器端计算diff补丁，然后在客户端应用它们。