我為什麼用 SQLite 和 FMDB 而不用 Core Data

標籤：

轉：http://segmentfault.com/a/1190000000363392編者註：文章的"我"是指原作者。

憑良心講，我不能告訴你不去使用Core Data。它不錯，而且也在變好，並且它被很多其他Cocoa開發人員所理解，當有新人加入你的組或者需要別人接手你的項目的時候，這點很重要。
更重要的是，不值得花時間和精力去寫自己的系統去代替它。真的，使用Core Data吧。

為什麼我不使用Core Data

Mike Ash寫到：

就我自己而言，我不是個狂熱粉絲。我發現API是笨拙的，並且架構本身對於大量的資料是極其緩慢的。

一個實際的例子：10,000條目

想象一個RSS閱讀器，一個使用者可以在一個feed上點擊右鍵，並且選擇標記所有為已讀。

引擎下，有一個帶有read屬性的Article實體。把所有條目標示讀取，程式需要載入這個feed的所有文章(可能通過一對多的關係)，然後設定read屬性為YES。

大部分情況下這樣沒關係。但是設想那個feed裡有200個文章，為了避免阻塞主線程，你可能考慮在後台線程裡做這個工作(特別當你的程式是一個iPhone應用)。當你一開始使用Core Data多線程，事情就開始變的不好處理了。

這可能還湊合，至少不值得切換走Core Data。

但是接下來加同步。

我用過兩種不同的擷取已讀文章ID列表的RSS同步介面。其中一個返回近10,000個ID。

你不會打算在主線程中載入10,000個文章，然後設定read為NO。你甚至不想在後台線程裡載入10,000個文章，即使很小心的管理記憶體，這有太多的工作（如果你頻繁的這麼做，想一下對電池壽命的影響）。

你真正想要做的是，讓資料庫給在ID列表裡的每一個文章設定read為YES。

SQLite可以做到這個，只用一次調用。假設uniqueID上有索引，這會很快。而且你可以在後台線程執行像在主線程執行一樣容易。

另一個例子：快速啟動

我想減少我的另一個程式的啟動時間，不只是開始的時間，而是在資料顯示之前的所有時間。

那是個類似Twitter的應用(雖然它不是)，它顯示訊息的時間軸。顯示時間軸意味著擷取訊息，載入相關使用者。它很快，但是在啟動的時候，會填充UI，然後填充資料。

關於iPhone的應用（或者所有應用）我的理論是，啟動時間很重要，比其他大部分開發人員想的都要重要。應用的啟動很慢看起來不像是要啟動一樣，因為人們潛意識裡記得，並且會產生阻止啟動應用的想法。減少啟動時間就減少了摩擦，讓使用者更有可能繼續使用你的應用，並且推薦給其他人。這是你讓你的應用成功的一部分。

因為我不使用Core Data，我手邊有一個簡單的，保守的解決方案。我把timeline（訊息和人物對象）通過NSCoding儲存到一個plist檔案中。啟動的時候它讀這個檔案，建立訊息和人物對象，UI一出現就顯示時間軸。

這明顯的減少了延遲。

把訊息和人物對象作為NSManagedObject的執行個體對象，這是不可能的。（假設我有編碼的並且儲存的IDs對象，但是那意味著讀plist然後觸及資料庫。這種方式我完全避免了資料庫）。

在更新更快的機器出來後, 我去掉了那些代碼。回顧過去，我希望我可以把它留下來。

我怎麼考慮這個問題

當考慮是否使用Core Data時，我考慮下面這些事情：

會有難以置信數量的資料嗎？

對於一個RSS閱讀器或者Twitter應用，答案顯而易見：是的。有些人關註上百個人。一個人可能訂閱了上千個feeds。

即使你的應用不從網路擷取資料，仍然有可能讓使用者自動添加資料。如果你用一個支援AppleScript的Mac，有些人會寫指令碼去載入非常多的資料。如果通過web API去加資料也是一樣的。

會有一個Web API包含類似於資料庫的終端嗎（對比類對象終端）？

一個RSS同步API能夠返回一個已讀文章的uniquelIDs列表。一個記筆記的應用的一個同步API可能返回已存檔的和已刪除的筆記的uniquelIDs。

使用者可能通過操作處理大量對象嗎？

在底層，需要考慮和之前一樣的問題。當有人刪除所有下載的5，000個麵食食譜，你的食譜應用可以多好的完成這個功能（在iPhone上？）？

當我決定使用Core Data（我已經發布過使用Core Data的應用），我會小心留意我怎麼使用它。為了得到好的效能，我發現我把它當做一個SQL資料庫的一個奇怪介面來使用，然後我知道我應該捨棄Core Data，直接使用SQLite。

我怎麼使用SQLite

我通過FMDB Wrapper來使用SQLite，FMDB來自Flying Meat Software，由Gus Mueller提供。

基本操作

我在iPhone以前，Core Data以前就使用過SQLite。這是它怎麼工作的的要點：

• 所有資料庫訪問-讀和寫-發生在連續的隊列裡，在一個後台線程。在主線程中觸及資料庫是從來不被允許的。使用一個連續隊列來保證每一件事是按順序發生的。
• 我大量使用blocks來讓非同步程式容易點。
• 模型對象只存在在主線程（但有兩個重要的例外），改變會觸發一個後台儲存。
• 模型對象列出來他們在資料庫中儲存的屬性。可能在代碼裡或者在plist檔案裡。
• 一些模型對象是唯一的，一些不是。取決於應用的需要（大部分情況是唯一的）。
• 對關係型資料，我儘可能避免連表查詢。
• 一些物件類型在啟動的時候就完全讀入記憶體，另一些物件類型可能只需要建立並維護一個他們的uniqueIDs的。NSMutableSet，所以不需要去觸及資料庫，我就知道已經有什麼。
• Web API的調用發生在後台線程，他們使用分開的模型對象。

我會通過我現在的應用的代碼來詳細描述。

資料庫更新

在我最近的應用中，有一個單一的資料庫控制器-VSDatabaseController，它通過FMDB來與SQLite對話。

FMDB區分更新和查詢。更新資料庫，app調用：

-[VSDatabaseController runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock]

VSDatabaseUpdateBlock很簡單：

typedef void (^VSDatabaseUpdateBlock)(FMDatabase *database);

runDatabaseBlockInTransaction也很簡單：

- (void)runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock {    dispatch_async(self.serialDispatchQueue, ^{        @autoreleasepool {            [self beginTransaction];            databaseBlock(self.database);            [self endTransaction];        }    });}

（注意我用自己的連續調度隊列。Gus建議看一下FMDatabaseQueue，也是一個連續調度隊列。我還沒能去看一下，因為它比FMDB的其他東西都要新。）

beginTransaction和endTransaction的調用是可嵌套的（在我的資料庫控制器裡）。在合適的時候他們會調用-[FMDatabase beginTransaction] 和 -[FMDatabase commit]。（使用事務是讓SQLite變快的關鍵。）提示：我把當前事務儲存在-[NSThread threadDictionary]。它很好擷取每一個線程的資料，我幾乎從不用其他的。

這兒有個調用更新資料庫的簡單例子：

- (void)emptyTagsLookupTableForNote:(VSNote *)note {    NSString *uniqueID = note.uniqueID;    [self runDatabaseBlockInTransaction:^(FMDatabase *database) {        [database executeUpdate:            @"delete from tagsNotesLookup where noteUniqueID = ?;", uniqueID];    }];}

這說明一些事情。首先SQL不可怕。即使你從沒見過它，你也知道這行代碼做了什麼。

像VSDatabaseController的所有其他公用介面，emptyTagsLookupTableForNote應該在主線程中被調用。模型對象只能在主線程中被引用，所以在block中用uniqueID，而不是VSNote對象。

注意在這種情況下，我更新了一個尋找表。Notes和tags是多對多關係，一種表現方式是用一個資料庫表映射note uniqueIDs和tag uniqueIDs。這些表不會很難維護，但是如果可能，我確實嘗試避免他們的使用。

注意在更新字串中的?。-[FMDatabase executeUpdate:] 是一個可變參數函數。SQLite支援使用預留位置?，所以你不需要把正真的值放入字串。這兒有一個安全問題：它協助精靈反對SQL插入。如果你需要避開某些值，它也為你省了麻煩。

最後，在tagsNotesLookup表中，有一個noteUniquelID的索引（索引是SQLite效能的又一個關鍵）。這行代碼在每次啟動時都調用：

[self.database executeUpdate:    @"CREATE INDEX if not exists noteUniqueIDIndex on tagsNotesLookup (noteUniqueID);"];

資料庫擷取

要擷取對象，app調用：

-[VSDatabaseController runFetchForClass:(Class)databaseObjectClass                              fetchBlock:(VSDatabaseFetchBlock)fetchBlock                       fetchResultsBlock:(VSDatabaseFetchResultsBlock)fetchResultsBlock];

這兩行代碼做了大部分工作：

FMResultSet *resultSet = fetchBlock(self.database);NSArray *fetchedObjects = [self databaseObjectsWithResultSet:resultSet                                                        class:databaseObjectClass];

用FMDB尋找資料庫返回一個FMResultSet. 通過resultSet你可以逐句迴圈，建立模型對象。

我建議寫通用的代碼去轉換資料庫行到對象。一種我使用的方法是用一個plist，映射column名字到對象屬性。它也包含類型，所以你知道是否需要調用 -[FMResultSet dateForColumn:]， -[FMResultSet stringForColumn:]或其他。

在我的最新應用裡我做了些簡單的事情。資料庫行剛好對應模型對象屬性的名字。所有屬性都是strings，除了那些名字以“Date”結尾的屬性。很簡單，但是你可以看到需要一個清晰的對應關係。

唯一對象

建立模型對象和從資料庫擷取資料在同一個後台線程。一擷取到，程式會把他們轉到主線程。

通常我有uniqued對象。同一個資料庫行結果始終對應同一個對象。

為了做到唯一，我建立了一個對象緩衝，一個NSMapTable，在init函數裡：_objectCache = [NSMapTable weakToWeakObjectsMapTable]。我來解釋一下：

例如，當你做一個資料庫擷取並且把對象轉交給一個視圖控制器，你希望在視圖控制器使用完這些對象後，或者一個不一樣的視圖控制器顯示了，這些對象可以消失。

如果你的對象緩衝是一個NSMutableDictionary，你將需要做一些額外的工作來清空緩衝中的對象。確定它對應的對象在別的地方是否有引用就變的很痛苦。NSMapTable是弱引用，就會自動處理這個問題。

所以：我們在主線程中讓對象唯一。如果一個對象已經在對象緩衝中存在，我們就用那個存在的對象。（主線程勝出，因為它可能有新的改變。）如果對象緩衝中沒有，它會被加上。

保持對象在記憶體中

有很多次，把整個物件類型保留在記憶體中是有道理的。我最新的app有一個VSTag對象。雖然可能有成百上千個筆記，但tags的數量很小，基本少於10。一個tag只有6個屬性：3個BOOL，兩個很小的NSstring，還有一個NSDate。

啟動的時候，app擷取所有tags並且把他們儲存在兩個字典裡，一個主鍵是tag的uniqueID，另一個主鍵是tag名字的小寫。

這簡化了很多事，不只是tag自動補全系統，這個可以完全在記憶體中操作，不需要資料庫擷取。

但是很多次，把所有資料保留在記憶體中是不實際的。比如我們不會在記憶體中保留所有筆記。

但是也有很多次，當不能在記憶體中保留對象時，你希望在記憶體中保留所有uniqueIDs。你會像這樣做一個擷取：

FMResultSet *resultSet = [self.database executeQuery:@"select uniqueID from some_table"];

resultSet只包含了uniqueIDs， 你可以儲存到一個NSMutableSet裡。

我發現有時這個對web APIs很有用。想象一個API調用返回從某個確定的時間以後的，已建立筆記的uniqueIDs列表。如果我本地已經有了一個包含所有筆記uniqueIDs的NSMutableSet，我可以快速檢查(通過 -[NSMutableSet minusSet])是否有漏掉的筆記，然後去調用另一個API下載那些漏掉的筆記。這些完全不需要觸及資料庫。

但是，像這樣的事情應該小心處理。app可以提供足夠的記憶體嗎？它真的簡化編程並且提高效能了嗎？

用SQLite和FMDB而不是Core Data，給你帶來大量的靈活性和聰明解決辦法的空間。記住有的時候聰明是好的，也有的時候聰明是一個大錯誤。

Web APIs

我的API調用在後台進程（經常用一個NSOperationQueue，所以我可以取消操作）。模型對象只在主線程，但是我還傳遞模型對象給我的API調用。

是這樣的：一個資料庫物件有一個detachedCopy方法，可以複製資料庫物件。這個複製對象不是引用自我用來唯一化的對象緩衝。唯一引用那個對象的地方是API調用，當API調用結束，那個複製的對象就消失了。

這是一個好的系統，因為它意味著我可以在API調用裡使用模型對象。方法看起來像這樣：

- (void)uploadNote:(VSNote *)note {    VSNoteAPICall *apiCall = [[VSNoteAPICall alloc] initWithNote:[note detachedCopy]];    [self enqueueAPICall:apiCall];}

VSNoteAPICall從複製的VSNote擷取值，並且建立HTTP請求，而不是一個字典或其他筆記的表現形式。

處理Web API傳回值

我對web傳回值做了一些類似的事情。我會對返回的JSON或者XML建立一個模型對象，這個模型對象也是分離的。它不是儲存在為了唯一性的模型緩衝裡。

這兒有些事情是不確定的。有時有必要用那個模型對象在兩個地方做本地修改：在記憶體緩衝和資料庫。

資料庫通常是容易的部分。比如：我的應用程式已經有一個方法來儲存筆記對象。它用一個SQL insert或者replace字串。我只需調用那個從web API傳回值產生的筆記對象，資料庫就會更新。

但是可能那個對象有一個在記憶體中的版本，幸運的是我們很容易找到：

VSNote *cachedNote = [self.mapTable objectForKey:downloadedNote.uniqueID];

如果cachedNote存在，我會讓它從downloadedNote中擷取值，而不是替換它（這樣可能違反唯一性）。這可以共用detachedCopy方法的代碼。

一旦cachedNote更新了，觀察者會通過KVO通知筆記，或者我會發送一個NSNotification，或者兩者都做。

Web API調用也會返回一些其他值。我提到過RSS閱讀器可能獲得一個已讀條目的大列表。這種情況下，我用那個列表建立了一個NSSet，在記憶體中更新每一個緩衝文章的read屬性，然後調用-[FMDatabase executeUpdate:]。

讓它工作快速的關鍵是NSMapTable的尋找是快速的。如果你找的對象在一個NSArray裡，我們該重新考慮。

資料庫遷移

Core Data的資料庫遷移很酷，當它可行的時候。

但是不可避免的，它是代碼和資料庫中的一層。如果你越直接使用SQLite，你更新資料庫越直接。

你可以安全容易的做到這點。

比如加一個表：

[self.database executeUpdate:@"CREATE TABLE if not exists tags "    "(uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);"];

或者加一個索引：

[self.database executeUpdate:@"CREATE INDEX if not exists "    "archivedSortDateIndex on notes (archived, sortDate);"];

或者加一列：

[self.database executeUpdate:@"ALTER TABLE tags ADD deletedDate DATE"];

應用應該在代碼的第一個地方用上面這些代碼設定資料庫。以後的改變只需加executeUpdate的調用 — 我讓他們按順序執行。因為我的資料庫是我設計的，不會有什麼問題（我從沒碰到效能問題，它很快）。

當然大的改變需要更多代碼。如果你的資料通過web擷取，有時你可以從一個新資料庫模型開始，重新下載你需要的資料。

效能技巧

SQLite可以非常非常快，它也可以非常慢。完全取決於你怎麼使用它。

事務

把更新封裝在事務裡。在更新前調用 -[FMDatabase beginTransaction] ，更新後調用-[FMDatabase commit]。

如果你不得不反正常化（ Denormalize）

反正常化讓人很不爽。這個方法是，為了加速檢索而添加冗餘資料，但是它意味著你需要維護冗餘資料。

我總是瘋狂避免它，直到這樣能有嚴重的效能區別。然後我會儘可能少得這麼做。

使用索引

我的應用程式中tags表的建立語句像這樣：

CREATE TABLE if not exists tags   (uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);

uniqueID列是自動索引的，因為它定義為unique。但是如果我想用name來查詢表，我可能會在name上建立一個索引，像這樣：

CREATE INDEX if not exists tagNameIndex on tags (name);

你可以一次性在多列上建立索引，像這樣：

CREATE INDEX if not exists archivedSortDateIndex on notes (archived, sortDate);

但是注意太多索引會降低你的插入速度。你只需要足夠數量並且是對的那些。

使用命令列應用

當我的app在模擬器裡運行時，我會列印資料庫的路徑。我可以通過sqlite3的命令列來開啟資料庫。（通過man sqlite3命令來瞭解這個應用的更多資訊）。

開啟資料庫的命令：sqlite3 “資料庫的路徑”。

開啟以後，你可以看schema: type .schema。

你可以更新和查詢，這是在使用你的app之前檢查SQL是否正確的很好的方式。

這裡面最酷的一部分是，SQLite Explain Query Plan命令，你會希望確保你的語句執行的儘可能快。

真實的例子

我的應用程式顯示所有沒有歸檔筆記的標籤列表。每當筆記或者標籤有變化，這個查詢就會重新執行一次，所以它需要很快。

我可以用SQL join來查詢，但是很慢（joins都很慢）。

所以我放棄sqlite3並開始嘗試別的方法。我又看了一次我的schema，意識到我可以反正常化。一個筆記的歸檔狀態可以儲存在notes表裡，它也可以儲存在tagsNotesLookup表。

然後我可以執行一個查詢：

select distinct tagUniqueID from tagsNotesLookup where archived=0;

我已經有了一個在tagUniqueID上的索引。所以我用explain query plan來告訴我當我執行這個查詢的時候會發生什麼。

sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0;0|0|0|SCAN TABLE tagsNotesLookup USING INDEX tagUniqueIDIndex (~100000 rows)

它用了一個索引，但是SCAN TABLE聽起來不太好，最好是一個SEARCH TABLE並且覆蓋一個索引。
我在tagUniqueID和archive上建了索引：

CREATE INDEX archivedTagUniqueID on tagsNotesLookup(archived, tagUniqueID);

再次執行explain query plan:

sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0;0|0|0|SEARCH TABLE tagsNotesLookup USING COVERING INDEX archivedTagUniqueID (archived=?) (~10 rows)

好多了。

更多效能提示

FMDB的某處加了緩衝statements的能力，所以當建立或開啟一個資料庫的時候，我總是調用[self.database setShouldCacheStatements:YES] 。這意味著對每個調用你不需要再次編譯每個statement。

我從來沒有找到使用vacuum的好的指引，如果資料庫沒有定期壓縮，它會越來越慢。我的應用程式會跑一個vacuum，但只是每周一次（它在NSUserDefaults裡儲存上次vacuum的時間，然後在開始的時候檢查是否過了一周）。
如果能auto_vacuum那更好，看 pragma statements supported by SQLite 列表。

其他酷的東西

Gus Mueller讓我涉及自訂SQLite方法的內容。我並沒有真的使用這些東西，既然他指出了，我可以放心的說我能找到它的用處。因為它很酷。

在Gus的文章裡，有一個查詢是這樣的：

select displayName, key from items where UTTypeConformsTo(uti, ?) order by 2;

SQLite完全不知道UITypes。但是你可以加核心方法，查看-[FMDatabase makeFunctionNamed:maximumArguments:withBlock:]。

你可以執行一個大的查詢來替代，然後評估每個對象。但是那需要更多工作。最好在SQL級就過濾，而不是在將表格行轉為對象以後。

最後

你真的應該使用Core Data，我不是在開玩笑。

我用SQLite和FMDB一段時間了，我對多得的好處感到很興奮，也得到非同一般的效能。
但是記住機器在變快，其他看你代碼的人期望看到他已經知道的Core Data, 另一些不打算看你的資料庫代碼。
所以請把這整篇文章看做一個瘋子的叫喊，關於他為自己建立的細節的瘋狂的世界，並把自己鎖在裡面。

請享受了不起的Core Data的文章（有點難過的搖頭）。

接下來，在查完Gus指出的自訂SQLite方法特性後，我會研究SQLite的full-text search extension。 總有更多的內容需要去學習。

我為什麼用 SQLite 和 FMDB 而不用 Core Data