同步问题

　　原先看起来简单的问题实际上很复杂，这是大多数软件项目中的典型情况。如果你的应用程序太复杂，以至于在客户端上必须有一个关系型数据库，这可能意味着你的企业数据库正在处理相当多的数据。在美国移动工作者通过CDPD或GRPS连接的概率较大。它们都是报文分组网络，提供了良好的全国性的连通性；但是典型情况下两种技术的费用都是基于传递的数据量的，由于这个原因，在这些网络上传递的数据量被最小化了。这意味着需要给同步进程添加附加的代码逻辑，只有这样才能使用户最后同步之后的被修改过的记录通过网络传递。在大多数应用程序中，即使数据发生了改变，大量查找数据也很罕见。你的设计过程必须识别这些元素，并建立计划在有线网络（或WiFi）上建立这种查找数据，以防止过长的下载和高额的访问费用。

　　当数据被同步到客户端时，一般都需要建立某种"清除"这些移动客户端的无效数据的策略。例如，对于典型的Pocket PC设备，总共可能有32MB内存。没有必要保存一个月前指定的投递地址和维修信息！还有应用程序层安全性的问题。如果你的应用程序与另一个企业应用程序同步，如果某个用户被排除在该企业应用程序之外（密码超期、用户离开了公司等等），这些改变也应该被同步到移动应用程序中。因为大多数数据库应用程序严重依赖于主键的原理为数据生成唯一的ID，因此需要设置某种策略，当设备A上的用户A建立一个新记录的时候（主键为123456），设备B上的用户B不能建立有相同主键的新记录。如果发生这种情况，当这条记录同步的时候，试图把它插入到企业数据库的时候会收到一个主键违规错误。

　　作为这些问题的补充，目前还有数据冲突的问题。假设移动用户A根据发送过程中收集的信息更新某个客户的家庭地址。在它同步前，返回办公室的某个人也修改了该客户的地址。当用户同步的时候，谁的更新会"胜利"？用户A是否能覆盖那个办公室用户的更新？希望不是这样。我们所需要的是某种识别并适当处理这些冲突的机制--通常通过更新一个或多个中间表实现，接着LAN用户可以手动查看这些冲突并决定哪种更新是有效的（由于用户更新了相同记录的不同字段，因此它们通常都有效）。

　　MobiLink同步

　　实际上当数据离开集中式RDBMS，被分割并通过电波发送到各处时还会出现其它一些问题。但是，为了避免你完全被移动数据库开发吓跑了，我只提供了一个通用的解决方案。在Sybase SQL Anywhere Studio 8开发工具包中包含了一种数据同步技术，即我们所知道的MobiLink，它包含了一个用于处理正在同步的用户的输入请求的多线程服务器应用程序（多种UNIX、Linux和Windows 2000/XP都支持）。MobiLink开发过程的一部分包括开发大量的将安装到目标服务器RDBMS的同步SQL脚本。典型情况下，数据库中的每个表有一个或多个同步脚本（处理上载和下载数据的多个脚本），以及允许同步安装和卸载的几个安装事件脚本（begin_synchronization、 begin_upload、end_download等等）。数据冲突通过MobiLink的冲突分辨进程处理，这个进程通过SQL同步脚本处理。尽管客户端数据库可能是ASA或UltraLite，但是MobiLink是数据库服务器无关的，因为它通过ODBC执行所有的同步操作。同时我需要提醒你，所有的SQL脚本都要使用目标数据库的SQL风格编写（MobiLink作为Sybase、Oracle和DB2的示例发布）。

　　在客户端，每个ASA或UltraLite数据库都配置了特定的"发布"信息，它指定用于同步的MobiLink服务器（服务器版本、IP地址和端口）。最后，它提供了Java和C API，允许客户端通过本地TCP/IP或 HTTP触发同步。同时它也支持RSA和ECC加密以确保数据传递是安全的。

　　结论

　　在本文中我们讨论了移动数据库开发的技术。我们提供的这些基本信息对于帮助你作明智的决定可能有好处。当移动应用程序的结构体系和开发都正确的时候，它可以提供显著的投资回报，因为移动工作人员是最希望能与实际客户联系的雇员。