核心數據VS Sqlite或FMDB ......？

Question

現在這可能看起來像一個重復的線程，但我的問題是我已經閱讀了很多問題，如核心數據與SQLite 3和其他人，但這些都是2 - 3年。 我還讀到FMDB是由於iOS上不支持核心數據而開發的，因此不應再使用它了。 而另一方面，我已經讀過，不應該將核心數據用作數據庫。

所以我很困惑，我是否應該使用核心數據進行對象存儲 。 我的意思是在什么基礎上我應該決定使用哪個？ 是否有蘋果或其他人提供的指導方針......或者是時間會來找我的東西。

Answer 1

ANKIT，

這是tl; dr skinny：使用Core Data。

這是長形式：

雖然您可以使用許多標准在Core Data，ORM（FMDB）或直接sqlite調用之間進行選擇，但這種選擇的實際成本來自您使用它的時間，Apple的支持以及其他項目的影響力。 （將REST服務映射到Core Data的RESTKit最近很受歡迎。）

因此，很大比例的時間，比如90 +％（一個編制的統計數據），iOS上的答案將是使用核心數據。 為什么？ 一旦掌握了它並構建了一些小幫助方法，Core Data就會讓您處於一致的計算世界 - Objective-C對象圖。 Core Data將教您如何使用動態語言，這將有助於iOS編程的其他方面。 因此，你的工作效率更高。 不要打架子。

如果您從另一個應用程序中引入一個大型，復雜的SQLite數據庫和模式，那么使用FMDB或SQLite可能具有成本效益。 但我對此表示懷疑。 您編寫一個簡單的基於Mac的命令行應用程序將數據庫遷移到Core Data DB的時間是一項有限且簡單的任務。 您幾乎可以保證必須重寫Objective-C中的大多數業務邏輯。 （是的，C ++和Objective-C ++都是很好的技術。你的數據庫業務邏輯是否真的被調整為在內存有限的設備上運行？我不這么認為。）

核心數據在性能方面受到了抨擊。 這真的很快。 您只需使用它而不是使用數據庫。 特別是，您幾乎總是從存儲中過度獲取數據，然后使用直接在各種集合和數組上的謂詞來優化它。 在iOS設備上，閃存速度非常慢，這種過度獲取策略特別有效。 實際上，這些設備上有很多RAM，用它來獲得性能。 （是的，我知道這與我上面對可移植業務邏輯的沖擊明顯矛盾。但實際上，從桌面或服務器環境移植的代碼有很多關於磁盤速度，內存量和實際情況的隱含假設。一個帶有后備存儲的虛擬機，它只能在電池供電，內存受限的設備上運行良好的內存模型。[它在Android設備上也無法正常工作。]）您還將對數據進行非規范化以簡化在各種iOS和Mac OS X UI小部件中顯示它。 有一些應用程序，其中Core Data將比同等的SQLite DB慢。 這些已在別處詳述。 一個主要的主張是上游數據庫定義ID的任務達到核心數據的性能是真實的。 但是，通過明智的索引和過度獲取可以稍微減輕它。

關於移動設備要記住的事情是，數據庫大小，因為這些是互聯網葉子上的移動設備，通常是適度的大小。 因此，性能更容易實現。 來自服務器世界的許多經驗教訓可能不適用於這個移動電池供電的世界。

換句話說，你必須“全押”才能在iOS / Mac OS X上使用Objective-C，你也可以通過使用Core Data獲得一些重要的生產力優勢。

安德魯

Answer 2

我最近自己踏上了這個旅程，最終嘗試了這三個。 這是我學到的：

• 原始sqlite3
  • 低級，完全訪問數據庫。 沒有抽象。 非常冗長 - 需要大量代碼才能完成非常簡單的事情。
• 核心數據
  • 非常高級，基於抽象，必須使用Apple生成的數據庫。 適用於iCloud同步和簡單的iOS數據管理。 直接訪問數據庫既困難又危險，不應該用於跨平台數據庫。 仍需要相當數量的代碼來完成簡單的事情。
• FMDB
  • 高級，非常抽象友好但不強迫。 如果需要，仍然可以完全訪問數據庫。 提供結果的NSDictionary ，每個項自動被類型化為正確數據類型的可變變體（例如，文本列作為NSMutableString返回）。 我最終圍繞它構建了一個非常簡單的包裝類來進一步抽象它，所以我有一個帶有靜態函數的輔助類，如selectAllFrom:(NSString *)table where:(NSDictionary *)conditions ，它返回NSDictionary對象的NSArray 。 能夠做到像NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];這樣的事情真是太棒了NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}]; 。

基本上，雖然核心數據可能對簡單的iOS應用程序很有用，但任何對使用跨平台數據庫感興趣的人都應該遠離它 - 蘋果公司沒有興趣讓它變得那么簡單，而且它表明了這一點。

---

TL; DR：

• 除非你做的事非常簡單，否則不要使用原始的sqlite3。
• 核心數據適用於簡單的iOS數據，如果您對鎖定它很舒服。
• 如果你想完全控制數據庫並且你沒有做一些微不足道的工作，或者你正在為多個平台構建你的應用程序，那么FMDB絕對是可行的方法。

Answer 3

我將FMDB用於所有大量使用“ INSERT ”並且FMDB沒有過時的項目。 Github的最后一次提交是去年11月。 如果你使用SQL，我建議你使用FMDB。

核心數據適用於所有項目的95％，但如果涉及優化以運行到牆上。 如果您想要Core Data（OOP，...）的好處，那么請使用它。 如果您有很多插入刪除與“ WHERE ”用戶Sqlite（FMDB）

此POST解釋了Core Date與Sqlite（FMDB）的關閉和頂級站點

Answer 4

CoreData 不只是一個SQL數據庫的抽象。 CoreData也可以進行對象圖管理。 CoreData可以做FMDB根本無法做到的事情。

一如既往：這取決於您的使用案例。 但在99％的情況下，CoreData是正確的選擇。

如果性能至關重要，您仍然必須了解數據庫的工作方式。 但是，如果以正確的方式使用CoreData，CoreData可以提供該性能。 但這需要一些時間來學習。 在CoreData中有許多事情是微不足道的，在FMDB中要做的事情非常復雜。

Answer 5

作為一個新的SQL人，我要投入兩分錢：

在Core Data中，您需要在實際使用數據庫之前輸入一些“樣板”代碼。 您的應用至少需要以下其中一項：

1. 持久性商店協調員
2. 托管對象上下文
3. 一個托管對象。 這與實體相關，如果您使用SQLite數據庫，則該實體與表相關聯。

要充分利用框架，您需要了解這些對象在數據管理中的作用。

另一方面，我們有SQLite，在我看來，它更容易理解。 首先，您需要：

1. 一個數據庫
2. 一張或多張桌子（取決於您的數據）
3. SQL知識 - 一種語言簡單的靈活語言（SELECT查詢比你原先認為的更多）
4. 應用程序通過其與SQLite通信的對象。

Answer 6

核心數據只是SQLite3數據庫的對象抽象化。 這意味着您可以輕松管理標准數據庫操作的持久對象。 您還可以在事務模式下工作，並通過創建模型在XCode中設計核心數據數據庫結構。

如果您不想手動創建SQLite3數據庫或持久性方法，請使用Core Data。