关于后台数据库设计的考虑(手机平台)

关于后台数据库设计的考虑(手机平台)

 

有人觉得，在手机运行一个数据库服务进程有些浪费。我们先考虑一下，手机有哪些数据可以存到数据库，名片、短信、邮件、彩信、通话记录、记事、日程、待办、闹钟等等都可以。SPEC常常要求名片可以存5000条，短信500条，通话记录300条。

 

在企业级应用中，5000条记录只是小case了，但在手机平台中，算是大量数据了。设计得不好，进入名片可能就要10几秒钟，名片反查速度也慢得不能接受。

 

要考虑性能，要考虑并发处理，要考虑死锁，要考虑掉电保护，要考虑磁盘坏块，如此等等。实现一个DBMS绝不是那么简单的事件。所以我们决定采用现存的DBMS，而不是重新开发一个。Sqlite是一个轻量级的，用于嵌入式应用，与SQL兼容的DBMS。

 

Sqlite编译出的二进制文件仅300K左右，性能上的表现也颇为不俗。但它不是C/S模型的，而是以API形式提供的，在当前进程中运行。我们决定把Sqlite改造为C/S模型的，作为一个后台服务进程运行。这样做有几个好处：

a)         多个应用程序之间可以共享数据，而互不关联。

b)        系统的运行更加稳定，不会因为应用程序不稳定，影响数据库。

c)        支持异步操作，操作大量数据时，用户不会感觉到界面无反应。

d)        便于实现发布订阅机制，让特殊应用程序可以关注数据库的变化，及时更新界面。

 

在客户端，针对具体的应用，封装一套面向对象的接口。ORM在这里实现，上层应用程序调用面向对象的接口，无需要关心关系数据库的存储。对象的存储和对象本身分开，在两个类中实现。如CallRecord表示通话记录类，CallRecordPersister表示通话记录存储类，CallRecordPersister负责从数据库加载对象和把对象存储到数据库中，而CallRecord类与数据库本身没有直接的关系。到时候，可以编写一个工具，用来产生这部分代码。

 

在数据库服务器端，实现发布订阅机制，让应用程序可以关注数据库的某些变化。比如短信应用程序的短信列表界面，可以关注短信数据库。当时MMI后台向数据库加入一条新短信时，后台数据库通知短信应用程序，短信应用程序再更新短信列表，保证数据显示与数据库内容一致。

 

进程间通信机制采用DBUS，DBUS是一个专为桌面环境(同一个机器上)开发的一个进程通信机制，有类似CORBA的功能，远程过程调用(同步/异步)，事件通知等等，但其开销相对CORBA而言非常小。

 

另外，提供一种方式把数据对象与GTK+控件绑定起来。若不涉及到界面操作，应用程序可以直接使用ORM接口。若涉及到界面显示和编辑，则应用程序采用后者的方式。让数据对象直接与控件绑定，使用起来更加方便。