我正在开发一个iOS应用程序，它将数据存储在sqlite3数据库中。每个插入，更新或删除操作都在本地记录，然后推送到iCloud，运行该应用程序的其他设备可以下载这些事务日志并在其中执行SQL命令，以使运行该应用程序的所有设备保持同步。这非常有效。
我现在正在考虑优化流程，我发现记录整个SQL命令会导致大量冗余数据被推送到云端，从而最终导致更长的同步时间和更多的数据使用量
SQL查询是非常可预测的（应用程序中使用的插入，更新和删除只有一种格式）所以我正在考虑使用编码/解码例程来压缩SQL命令以便在事务日志中存储，然后从日志中解压缩以便执行。
我发现的字符串压缩方法似乎不太适合SQL查询，所以我设计了自己的：
使用这种格式我压缩了一个186字节的示例查询，只有78字节。这对于数据传输的速度和数据使用量具有明显的优势。
我预见的缺点是它需要在客户端进行更多处理以对命令进行编码和解码。我想知道是否有人做过类似的事情，并且有任何建议。
使我更清楚的是：通常最好是最小化同步的数据量并增加客户端解释这些数据的负担，或者最好是按原样同步数据让客户端按原样使用它？
答案 0 :(得分：0)
我正在回答我自己的问题，因为我有一些信息可以为正在寻找相同事物的其他人提供建议。
我昨天花了一些时间在Objective C中编写SQL查询压缩和解压缩函数。这些函数使用我原始问题中详述的方法，这样做可以减少查询的所有非数据部分（SQL命令[insert / update /删除]，表名和列名）到一个数字来表示每个，并删除所有剩余的SQL语法（关键词如“FROM”，空格，逗号，括号......）。
我已经通过创建五条记录进行了一些测试，无论是否启用了查询压缩，以下是文件大小的结果：
完整SQL查询（未经修改记录到事务文件中）
压缩的SQL查询（使用我的自定义格式压缩到事务文件）
如您所见，最大的好处是使用两种类型的压缩。对查询进行编码实现了~50％的压缩。与压缩未编码的查询相比，编码然后压缩查询实现了大约10％的压缩。
我现在真正需要问自己的问题是，编码然后压缩查询是否值得额外开销，并在从其他设备下载事务日志后解压缩并解码它们。在这个例子中，我只通过编码保存了74个字节，然后压缩了事务日志。有五个查询，每个查询平均节省14.8个字节（与单独压缩相比）。这只是每1000条记录14.4kb，这似乎并不多。