現在這可能看起來像一個重複的線程，但我的問題是，我讀了很多問題，如.. Core Data vs SQLite 3和其他人，但這些都是2-3歲。我還讀過FMDB是在iOS上不支持核心數據的情況下開發的，因此不應再使用它。另一方面，我已經讀過，不應該使用核心數據作爲數據庫。核心數據VS Sqlite或FMDB ....？
所以我很困惑，我是否應該使用核心數據來存儲對象或不是。我的意思是我應該決定使用哪個基礎？是否有任何指導方針由蘋果或其他人提供？或者它會隨着時間的推移而來。
ANKIT關和頂位，
這裏的tl;博士瘦：使用核心數據。
這裏的長型：
雖然你可以使用許多標準的核心數據，一個ORM（FMDB）或直接sqlite的通話之間進行選擇，這種選擇的真正的成本來自於你的時間使用它，蘋果公司支持和利用其他項目。 （將REST服務映射到核心數據的REST Kit現在很流行）。
因此，很大一部分時間，比如90 +％（一個統計數據），iOS上的答案將用於核心數據。爲什麼？一旦掌握了它並創建了一些小的幫助器方法，Core Data就會使您保持一致的計算世界 - Objective-C對象圖。核心數據將教你如何使用動態語言，這將有助於你的iOS編程的其他方面。因此，你更有成效。不要打架。
如果您從其他應用程序引入大型複雜SQLite數據庫&架構，那麼使用FMDB或SQLite可能具有成本效益。但我懷疑它。編寫簡單的基於Mac的命令行應用程序將數據庫遷移到核心數據DB的時間是一項有限而簡單的任務。您幾乎可以保證必須重寫Objective-C中的大部分業務邏輯。 （是的，C++和Objective-C++都是很好的技術，你的數據庫業務邏輯是否真的被調整用於限制內存的設備上？我不這麼認爲）。
核心數據在性能上受到了熱捧。這真的很快。您只需要使用它與使用數據庫不同。特別是，您幾乎總是從存儲中過度獲取數據，然後使用謂詞直接在各種集合和數組上進行優化。在iOS設備上，閃存出人意料地很慢，這種超取策略特別有效。你在這些設備上實際上有很多RAM，用它來獲得性能。 （是的，我知道這與我上面提到的便攜式業務邏輯存在明顯的矛盾，但實際上，從桌面或服務器環境移植的代碼對於磁盤速度，內存數量和實際情況有着許多隱含的假設一臺具有後備存儲的虛擬機，在電池供電，內存有限的設備上使用時髦的內存模式，它不能很好地工作[在Android設備上它也不能很好地工作。]）您還可以非規範化數據以簡化將其顯示在各種iOS和Mac OS X UI小部件中。有一些應用程序的核心數據將比等效的SQLite數據庫慢。這些在其他地方已經詳述一個主要的主張是，由上游數據庫定義ID的任務觸及Core Data的性能是真實的。但是可以通過明智的索引和過度提取來緩解。
有關移動設備的事情要記住的一點是，數據庫的大小，因爲這些是互聯網葉子上的移動設備，通常是適度的大小。因此，表現更容易達到。來自服務器世界的許多經驗教訓可能不適用於這種移動電池供電的世界。
換句話說，您必須全程使用iOS/Mac OS X上的Objective-C，您才能從使用Core Data獲得一些重要的生產力優勢。
安德魯
作爲目前的維護者Jeff LaMarche的SQLite持久對象，我補充說FMDB是適合使用的SQLite包裝。僅僅因爲它最近沒有更新並不表示放棄，而是成熟。例如，我維護Apple的Reachability代碼版本，
核心數據只是SQLite3數據庫的對象抽象化。這意味着您將擁有易於管理標準數據庫操作的持久對象。您也可以在事務模式下工作，並通過創建模型在XCode中設計核心數據庫結構。
如果您不想手動創建SQLite3數據庫或持久性方法使用核心數據。
那麼我們可以完全排除FMDB嗎？ – 2012-01-04 08:57:34
我認爲使用FMDB是因爲核心數據在iOS中不可用<3.0 – 2012-01-04 09:10:22
核心數據不是數據庫：http://cocoawithlove.com/2010/02/differences-between-core-data-and.html。核心數據使用數據庫eq Sqlite來存儲數據。 – CarlJ 2012-01-04 13:54:34
對於我所有使用「INSERT s」的項目，我使用FMDB，並且FMDB沒有過期。 Github上最後一次提交是在去年11月。如果你使用SQL，我建議你使用FMDB。
核心數據適合所有項目的95％，但如果涉及到優化運行到牆上。如果你想要核心數據（OOP，...）的好處，那就使用它。如果你有很多插入一個與「WHERE」用戶sqlite的（FMDB）刪除
這POST解釋核心日期與sqlite的（FMDB）
我不明白爲什麼要使用包裝而不是直接使用Objective-C sqlite3函數。我通常使用Core Data來進行模型設計。 – 2012-01-04 10:06:42
簡單：它更易於使用！你不用自己處理sqlite的「鎖定」狀態，它的線程保存，模式匹配，你可以使用普通的基礎對象，你的代碼更乾淨。 （FMDB）6行代碼與10 ++代碼行與sqlite – CarlJ 2012-01-04 10:19:20
我認爲你的代碼比Core Data更清晰，最重要的是容易維護（通過逆向工程）。 – 2012-01-04 11:06:06
CoreData是不只是一個SQL數據庫的抽象。 CoreData也是對象圖管理。 CoreData可以做FMDB根本做不到的事情。
一如既往：這取決於您的使用案例。但在99％的案例中，CoreData是正確的選擇。
如果性能至關重要，您仍需瞭解數據庫的工作方式。但是如果您使用正確的方式，CoreData可以提供這種性能。但是需要一些時間來學習。在CoreData中做很多事情是微不足道的，這在FMDB中會非常複雜。
我將通過FMDB並在未來的項目中使用核心數據。謝謝... – 2012-01-05 10:12:09
我最近自己踏上了這段旅程，最終嘗試了三種。這是我學到：
NSDictionary，每個項目自動鍵入適當數據類型的可變變體（例如，文本列的返回形式爲NSMutableString）。我最終圍繞它構建了一個非常簡單的包裝類，以更多地抽象它，所以我有一個帶有靜態函數的幫助類，如selectAllFrom:(NSString *)table where:(NSDictionary *)conditions，它返回NSArray的NSDictionary對象。能夠做到像NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];這樣的事情真是太棒了。基本上，而核心數據可用於簡單的iOS專用的應用程序，任何人誰是熱衷於使用跨平臺數據庫應該留遠，遠離它是有用的 - 蘋果公司在做那麼容易沒有興趣，它表明。
TL; DR：
作爲一個新的SQL的傢伙，我要去把我的0.02：
在覈心數據，你有一點的「樣板」的代碼，你需要把之前你可以真正使用你的數據庫。您的應用程序至少需要以下其中一項： 1）持久性商店協調員 2）受管理對象上下文 3）受管理對象。這與一個實體相關，如果您使用SQLite數據庫，則該實體與表關聯。
要充分利用框架，您需要了解這些對象在管理數據中扮演的角色。
另一方面，我們有SQLite，在我看來，它更容易理解。首先，你需要： 1）一個數據庫 2）一個表或更多（取決於你的數據） 3）SQL知識 - 一種靈活的語言與一個簡單的語法（SELECT查詢做的比你最初的認爲他們） 4）一個對象，通過它你的應用程序與SQLite進行通信。
你要存儲什麼數據，有多少數據，你需要做什麼檢索，用戶可以編輯？ – jrturton 2012-01-04 08:29:16
這就是我的問題所在。我的意思是我應該決定使用哪種方式，並且是否有任何由蘋果或其他人提供的指導方針......或者是隨着時間的推移而來的東西。 – 2012-01-04 08:31:49
如果您需要一次更新，插入或刪除多行，那麼Core Data不是一個好選擇。 – AechoLiu 2012-01-04 10:23:19