我準備好深入我的第一個核心數據冒險。在對框架進行評估時,出現了兩個問題,真的讓我想到了在這個項目中使用Core Data或者堅持使用SQLite。對核心數據的擔憂
我的應用程序將嚴重依賴於從外部來源導入數據。我意識到可以導入到Core Data中,但處理複雜的關係看起來很複雜和乏味。有沒有簡單的方法來完成複雜的進口?
該應用程序必須能夠執行跨多個表或具有多個條件的複雜查詢。建立這些謂詞和表達式只會讓我感到恐慌......
是否值得冒險和使用Core Data或者我應該堅持使用SQLite?
我準備好深入我的第一個核心數據冒險。在對框架進行評估時,出現了兩個問題,真的讓我想到了在這個項目中使用Core Data或者堅持使用SQLite。對核心數據的擔憂
我的應用程序將嚴重依賴於從外部來源導入數據。我意識到可以導入到Core Data中,但處理複雜的關係看起來很複雜和乏味。有沒有簡單的方法來完成複雜的進口?
該應用程序必須能夠執行跨多個表或具有多個條件的複雜查詢。建立這些謂詞和表達式只會讓我感到恐慌......
是否值得冒險和使用Core Data或者我應該堅持使用SQLite?
由於I和others之前已經說過,Core Data實際上是一個對象圖管理框架。它管理模型對象之間的關係,包括基數約束和管理級聯刪除等。它還管理對各個屬性的約束。核心數據只是發生也能夠將該對象圖持久化到磁盤。它可以通過多種格式來完成,包括XML,二進制和SQLite。因此,核心數據實際上與SQLite正交。如果您的任務正在處理嵌入式SQL兼容數據庫,請使用SQLite。如果您的任務正在管理MVC應用程序的模型層,請使用Core Data。在具體問題的答案:
有沒有神奇的,可以複雜的數據自動導入到任何模型。也就是說,這在Core Data中相對容易。採取multi-passapproach並且使用SQLite後端可以幫助您節省內存,因爲您一次只能保留內存中的一部分數據。如果數據集可以保存在內存中,則可以編寫自定義持久性存儲格式,從Core Data中直接讀取/寫入舊數據格式(請參閱Atomic Store Programming Guide)。
聲明性地構建一個複雜的NSPredicate
有點冗長,但不應該嚇倒你。 Predicate Programming Guide是一個很好的開始。當然,您也可以使用字符串格式編寫謂詞,就像字符串格式的SQL語句一樣。值得注意的是,如上所述,核心數據中的謂詞位於對象和對象圖上,而不在SQL表上。如果你真的想想在表的層面上,堅持與SQLite並編寫自己的包裝。
我不能真正說出你的第一點。但是,關於第二點,使用核心數據意味着您不必擔心複雜的查詢,因爲您可以假裝所有關係都已在內存中正確建立(不考慮Apple的實現細節)。無論數據庫環境中的聯接有多複雜都無關緊要,因爲您確實不在數據庫環境中。如果您需要獲取當前對象的祖父母的第四個孩子,然後找到該孩子的寵物的名稱和品種,則只需使用一系列消息或屬性在代碼中遍歷對象樹。不用擔心連接或任何事情。唯一的問題是它可能真的很慢取決於你的對象的關係,但是我不能準確地說出這個問題,因爲我沒有真正實現任何使用Core Data的東西(我剛剛在蘋果公司和其他公司'網站)。
如果從外部源的數據進口商被寫入基於相同的核心數據模型(用於導入的靶向/目的地側) - 沒有什麼會是概念上不同的作爲比較,使用/更新相同的數據(通過實際應用程序的核心數據堆棧)。
如果您在不使用核心數據堆棧的情況下創建數據導入器,請確保您很好地學習了基於核心數據模型生成/預期的數據庫模式。這裏沒有任何魔法 - 只要確保遵循跨實體關係的實現方式以及實體層次結構的存儲方式。
我不得不最近從Access數據庫創建一個數據導入器到基於Sqlite核心數據庫的.NET應用程序中。一旦我的目標核心數據模型被定義,我創建了一個小應用程序,用隨機生成的實體(包括所有預期的關係)填充Sqlite存儲區。然後,我逆向設計了核心數據是如何爲模型創建Sqlite存儲的,以及如何通過從生成和持久數據中學習來處理關係。然後,根據我的觀察,我實現了基於.NET的導入器/數據轉換器。最後,我得到了完美的核心數據友好型數據存儲,可以從使用Mac OSX上的核心數據堆棧的應用程序打開修改。
我知道這個問題有點老,但你是如何解決你的第一點的?我有一個非常相似的場景,聽到你的解決方案會很高興。謝謝。 – 2012-08-23 17:32:08