（轉：http://blog.csdn.net/dawnranger/article/details/43231731）

一、背景知識

ORM(Object Relation Mapping):物件關係模型。用於實現面向物件程式語言裡不同型別系統的資料之間的轉換。從效果上說，它其實是建立了一個可在程式語言裡使用的“虛擬物件資料庫”。ORM作為專案中介軟體形式實現資料在不同場景下資料關係對映，物件關係對映是一種為了解決面向物件與關係資料庫存在的互不匹配的現象的技術。

Android常用幾個ORM框架：ORMLite、GreenDao、ormndroid、androrm等。ORMLite和GreenDao的比較：

• ORMLite：文件全面，社群活躍，維護良好，使用簡單，容易上手，但是因為基於反射，所效率較低
• GreenDao：使用code generation,效率很高；庫檔案較小(約87KB)，佔用更少記憶體, 缺點是學習成本較高，需要弄清楚其原理才能方便使用

二、原理簡介

GreenDao向SQLite資料庫提供了一個物件導向的介面，它為使用者省下了很多重複的工作，而且提供了簡便的操作介面。
為了使用GreenDao，需要在新建一個Java工程（工程中需要匯入greendao-generator-x.x.x.jar，freemarker-x.x.xx.jar），根據GreenDao的規則在其中描述資料庫的表結構，執行之後它會構建你的實體模型和DAO工具類。具體包括：

DaoMaster:

• 持有資料庫物件(SQLiteDatabase) ，並管理一些DAO類(不是物件)
• 能夠建立和刪除資料庫表
• 它的內部類OpenHelper和DevOpenHelper是SQLiteOpenHelper的實現類，用於建立SQLite資料庫的模式

DaoSession:

• 管理制定模式下所有可用的DAO物件
• 能對實體進行插入、載入、更新、重新整理、刪除操作。

DAO:

• 每個實體都有一個DAO，相對於DaoSession,它有更多的方法，比如：載入全部、InsertTx

Entity

• 可持久化的物件，由generator 生成。相當於資料庫中的一張表，所有欄位都是使用標準的Java物件的屬性

通過generator生成的這些工具類，你就可以在自己的Android工程中對進行資料庫操作，完全不需要寫任何SQL語句。

三、建表

資料庫建立：在應用中通過DaoMaster的DevOpenHelper完成。

注：在生成的實體類中,int型別會自動轉為long型別

greenDAO會自動根據實體類屬性建立表字段，並賦予預設值。例如在資料庫方面的表名和列名都來源於實體類名和屬性名。預設的資料庫名稱是大寫使用下劃線分隔單詞，而不是在Java中使用的駝峰式大小寫風格。例如，一個名為“CREATIONDATE”屬性將成為一個數據庫列“CREATION_DATE”。

在使用greenDAO時，一個實體類只能對應一個表，目前沒法做到一個表對應多個實體類，或者多個表共用一種物件型別。後續的升級也不會針對這一點進行擴充套件。

四、表的增刪改查

1.查詢：

(1)QueryBuilder：
普通用法：

巢狀情況：(查詢1970年9月之後出生的使用者)

(2)Query：
可多次執行的查詢，使用QueryBuilder實際上呼叫了Query類，若果相同的查詢要執行多次的話，那應該呼叫QueryBuilder的build()方法來建立Query，而不是直接使用Query。

只返回一個結果：呼叫Query或者QueryBuilder的unique()方法，如果不希望返回null，那麼可呼叫uniqueOrThrow()方法。
返回多個結果：

• list() 所有實體被載入到記憶體中，結果通常是一個ArrayList
• listLazy() 實體在需要時才載入記憶體。表中的一個元素被第一次訪問時會被快取，下次再訪問時使用快取
• listLazyUncached() 任何對列表元素的訪問都會導致從資料庫中載入
• listIterator() 以按需載入的方式來遍歷結果，資料沒有被快取。

後三種方式使用了LazyList類，持有了一個資料庫cursor來實現按需載入。這樣是為了確保關閉LazyList和iterators。
一旦所有元素都被訪問或遍歷過，來自listLazy()的cache lazy list和來自listIterator()方法的lazy iterator將會自動關閉cursor。
然而，如果list...的處理過早的完成了，你應該呼叫 close()手動關閉。

(3)提高多次查詢效率
一旦使用QueryBuilder建立了一個query，那麼這個Query物件就可以就可以被複用來執行查詢顯然這種方式逼重新建立一次Query效率要高。
具體來說：

• 如果Query的引數沒有變更，你只需要再次呼叫List/unuque方法即可
• 如果引數發生了變化，那麼就需要通過setParameter方法來處理每一個發生改變的引數。

舉例：

現在複用該Query物件：

由此可見，Query在執行一次build之後會將查詢結果進行快取，方便下次繼續使用。

(4)原生SQL語句
兩種方法：

如果這裡的QueryBuilder沒有提供你想要的特性，可以使用原始的queryRaw或queryRawCreate方法。

注：寫SQL語句時推薦定義常量來表示表名或者表項，這樣可以防止出錯，因為編譯器會檢查。

(5)刪除
一次性刪除多個指定條件的資料：呼叫QueryBuilder的buildDelete方法，它會返回一個DeleteQuery。
如果資料被快取過，你可以啟用那些將要被刪除的實體。如果導致了一些使用的問題。你可以考慮清除identity scope。

(6)除錯
如果你的query沒有返回期望的結果，這裡有兩個靜態的flag，可以開啟QueryBuilder身上的SQL和引數的log。

它們會在任何build方法呼叫的時候打印出SQL命令和傳入的值。這樣你可以對你的期望值進行對比，或許也能夠幫助你複製SQL語句到某些
SQLite 資料庫的檢視器中，執行並獲取結果，以便進行比較。

(7)其它
統計查詢：queryBuilder.buildCount().count();
獲取全部記錄：noteDao.loadAll();

2.插入、更新

普通方法：

更新、批量插入：

關於資料操作的效能問題：(摘自官網)

Inserting/updating/deleting entities runs very slow. What’s wrong?
Probably, you are inserting/updating/deleting entities without using a transaction. Thus each operation is considered a transaction and SQLite needs to write to disk and do a file sync for each operation. Running all operations in a single transaction is essential for performance (and usually makes sense in terms of consistency). It will run a magnitude faster. For example, running 1,000 inserts in a single transaction ran 500 times faster (!) than 1000 individual transactions in one of our performance tests.

In greenDAO, use DaoSession.runInTx(Runnable) to make the given Runnable run as a transaction. If you have a list of entities of the same type, you can use the insertInTx or updateInTx methods of the DAO class belonging to the entity.


效能對比：
普通用法：400條插入，大約5秒

開多執行緒：0.1s以內

批量插入：0.1s以內

3.刪除

清空資料表：

刪除些資料：

Deletes all matching entities without detaching them from the identity scope