關於後臺資料庫設計的考慮(手機平臺)

關於後臺資料庫設計的考慮(手機平臺)

 

有人覺得，在手機執行一個資料庫服務程式有些浪費。我們先考慮一下，手機有哪些資料可以存到資料庫，名片、簡訊、郵件、彩信、通話記錄、記事、日程、待辦、鬧鐘等等都可以。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介面。若涉及到介面顯示和編輯，則應用程式採用後者的方式。讓資料物件直接與控制元件繫結，使用起來更加方便。