我们面对的产品很复杂，解决方案也很多样，导致技术实现上面，难点多，故障也很多。两个系统涉及到SmartClient的应用，其实本身而言，SmartClient的应用并不是很复杂，但是数据库的同步的确很复杂，其复杂点在于：

• 服务器端存储全量数据，客户端下载的是部分数据，这些部分数据的拆分依据比较难以实现，尤其是对于现有的数据库表。
• 客户端数据上传的时候，对于新增和更新的记录都比较好处理，对于删除的记录则很难，一方面要保证单个客户端的删除能够在其他的客户端上面生效，而另外一方面则需要保证其他客户端传上来被当前客户端删除的数据的时候，应该不是新建操作，而是什么也不做。
• 客户端和服务器端的吞吐量控制。数据量的大小，从根本上来说是和数据库设计数据库结构有关系，相同的数据结构下的相同数据量，轻量级的数据库的容量会小于大型的数据库，所以尽量采用轻量的数据库作为传输。这样就带来另外的问题，就是异构数据库下面的数据导入问题。
• 数据库文件格式的问题。数据库拆分之后，是使用数据库文件、DUMP文件、SQL语句或者其他的转储格式进行传输，这是一个见仁见智的问题。
• 通信协议的问题。使用TCP/IP直连？FTP文件传输？甭考虑直接连接服务器数据库了，如果是这样，还用得着同步数据库吗？

我们的解决方案很简单：

• 客户端和服务器端可以采用异构的数据库，但是前提是数据库里面的数据结构和表结构必须一致，同时，两个数据库必须都是SQL92标准的。
• 服务器端拆分数据库之后，生成一个同样数据结构和表结构的SQLite数据库文件，数据插入这个数据库文件中，并使用这个文件完成服务器和客户端的同步。
• 数据库文件使用ZIP压缩减少网络带宽。
• 传输通信协议可以是Remoting或者WebService
• 拆分数据库的数据依据根据业务系统不同而不同。
• 拆分数据库中保存删除的记录信息，单独的一张表格记录 哪张表格删除了那些数据。对于新增和修改记录不做单独的特殊存储。
• 同步的时候依文件数据库中的数据为准进行更新和新增操作。
• 增量数据区分不同的客户，不同的客户端生成的增量数据集不同。
• 提供全量数据一次性导入的功能。

对于真正实现的技巧，我们在下一篇文章中继续。