憑良心講，我不能告訴你不去使用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呼叫：
|
1 |
-[VSDatabaseController runDatabaseBlockInTransaction:(VSDatabaseUpdateBlock)databaseBlock] |
VSDatabaseUpdateBlock很簡單：
|
1 |
typedef void (^VSDatabaseUpdateBlock)(FMDatabase *database); |
runDatabaseBlockInTransaction也很簡單：
|
1 2 3 4 5 6 7 8 9 |
- (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]。它很好獲取每一個執行緒的資料，我幾乎從不用其他的。
這兒有個呼叫更新資料庫的簡單例子：
|
1 2 3 4 5 6 7 |
- (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效能的又一個關鍵）。這行程式碼在每次啟動時都呼叫：
|
1 2 |
[self.database executeUpdate: @"CREATE INDEX if not exists noteUniqueIDIndex on tagsNotesLookup (noteUniqueID);"]; |
資料庫獲取
要獲取物件，app呼叫：
|
1 2 3 |
-[VSDatabaseController runFetchForClass:(Class)databaseObjectClass fetchBlock:(VSDatabaseFetchBlock)fetchBlock fetchResultsBlock:(VSDatabaseFetchResultsBlock)fetchResultsBlock]; |
這兩行程式碼做了大部分工作：
|
1 2 3 |
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。你會像這樣做一個獲取：
|
1 |
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呼叫裡使用模型物件。方法看起來像這樣：
|
1 2 3 4 |
- (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返回值生成的筆記物件，資料庫就會更新。
但是可能那個物件有一個在記憶體中的版本，幸運的是我們很容易找到：
|
1 |
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，你更新資料庫越直接。
你可以安全容易的做到這點。
比如加一個表：
|
1 2 |
[self.database executeUpdate:@"CREATE TABLE if not exists tags " "(uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE);"]; |
或者加一個索引：
|
1 2 |
[self.database executeUpdate:@"CREATE INDEX if not exists " "archivedSortDateIndex on notes (archived, sortDate);"]; |
或者加一列：
|
1 |
[self.database executeUpdate:@"ALTER TABLE tags ADD deletedDate DATE"]; |
應用應該在程式碼的第一個地方用上面這些程式碼設定資料庫。以後的改變只需加executeUpdate的呼叫 — 我讓他們按順序執行。因為我的資料庫是我設計的，不會有什麼問題（我從沒碰到效能問題，它很快）。
當然大的改變需要更多程式碼。如果你的資料通過web獲取，有時你可以從一個新資料庫模型開始，重新下載你需要的資料。
效能技巧
SQLite可以非常非常快，它也可以非常慢。完全取決於你怎麼使用它。
事務
把更新包裝在事務裡。在更新前呼叫 -[FMDatabase beginTransaction] ，更新後呼叫-[FMDatabase commit]。
如果你不得不反規範化（ Denormalize）
反規範化讓人很不爽。這個方法是，為了加速檢索而新增冗餘資料，但是它意味著你需要維護冗餘資料。
我總是瘋狂避免它，直到這樣能有嚴重的效能區別。然後我會盡可能少得這麼做。
使用索引
我的應用中tags表的建立語句像這樣：
|
1 2 |
CREATE TABLE if not exists tags (uniqueID TEXT UNIQUE, name TEXT, deleted INTEGER, deletedModificationDate DATE); |
uniqueID列是自動索引的，因為它定義為unique。但是如果我想用name來查詢表，我可能會在name上建立一個索引，像這樣：
|
1 |
CREATE INDEX if not exists tagNameIndex on tags (name); |
你可以一次性在多列上建立索引，像這樣：
|
1 |
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表。
然後我可以執行一個查詢：
|
1 |
select distinct tagUniqueID from tagsNotesLookup where archived=0; |
|
1 2 |
sqlite> explain query plan select distinct tagUniqueID from tagsNotesLookup where archived=0; 0|0|0|SCAN TABLE tagsNotesLookup USING INDEX tagUniqueIDIndex (~100000 rows) |
我在tagUniqueID和archive上建了索引：
|
1 |
CREATE INDEX archivedTagUniqueID on tagsNotesLookup(archived, tagUniqueID); |
再次執行explain query plan:
|
1 2 |
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的帖子裡，有一個查詢是這樣的：
|
1 |
select displayName, key from items where UTTypeConformsTo(uti, ?) order by 2; |
SQLite完全不知道UITypes。但是你可以加核心方法，檢視-[FMDatabase makeFunctionNamed:maximumArguments:withBlock:]。
你可以執行一個大的查詢來替代，然後評估每個物件。但是那需要更多工作。最好在SQL級就過濾，而不是在將表格行轉為物件以後。
最後
你真的應該使用Core Data，我不是在開玩笑。
所以請把這整篇文章看做一個瘋子的叫喊，關於他為自己建立的細節的瘋狂的世界，並把自己鎖在裡面。
請享受了不起的Core Data的文章（有點難過的搖頭）。
接下來，在查完Gus指出的自定義SQLite方法特性後，我會研究SQLite的full-text search extension. 總有更多的內容需要去學習。