2013-03-15 62 views
4

我有一個相當複雜的數據結構,我打算在iPhone/iPad應用程序中使用。在擺脫了許多不需要的表格之後,儘可能地將數據結構扁平化。 - 也就是說,如果我有一個實際結構中的調用表和地址表,因爲我根本不需要更新地址信息,所以我擴展了IOS調用表以獲取地址信息而不是鏈接表 - 基本上是de儘可能地減少表格複雜度。對ios上的複雜數據結構的sqlite或coredata

總而言之,我仍然有15張桌子。

我可以很容易地將表腳本編寫到SQLlite中,並且可以快速使用IOS中的SQLlite C API並使其工作正常。

我的問題是 - 對於具有大量相關表的故障處理大數據捕獲應用程序,我應該堅持使用SQL技能並使用SQLite和C API,還是將其全部轉換爲coredata?

我與coredata主要的擔心是 一)建立時間 - 有從現有的數據庫模式創建coredata映射數據(SQL服務器,SQLite的或腳本) B)的方式,如果我有幾千行在一個表格中(這是在作業中使用的庫存項目清單)。我的理解是,coredata檢索該對象的所有項目,然後使用謂詞過濾它們。這究竟是如何運作的,還是我誤解了?如果它的行爲如此有效,這是否有效? c)雖然我儘可能地扁平化了結構,但仍然可能需要我一起加入3或4個表格 - 在覈心數據中使用這樣的關係是有效的嗎?

我沒有問題重讀coredata書籍,然後應用它,如果它真的是這種情況的更好的解決方案,它只是所有的書籍和我讀過的例子是1或2個具有一些屬性的實體只有一個關係。我的數據庫模式,所以我的coredata數據模型將比這更復雜。 另一個需要考慮的問題是核心數據是否比sqllite提供了使用rest服務或JSON從服務器獲取數據並將轉換完成細節返回給服務器的優勢?


請參閱下面我的經驗: 的情況下,任何人讀這篇文章,想知道我的經驗作爲SQL Server/ASP.net傢伙....

我開始使用SQLite的,我發現它使用起來既快又簡單。該API並不是很好,但作爲一個SQL人,這根本沒有給我帶來任何好處。

我能夠從SQL Server腳本表結構容易與小器官功能障礙綜合徵生成的腳本讓我在我的SQLite表結構非常迅速

我在訪問asp.net開始了,所以我沒有對腳本和創建動態SQL字符串很陌生。然而,我不想再使用這種方法,因爲我覺得它已經過時了,所以儘管可能矯枉過正,因爲我使用SQLite來檢索數據,但我想將數據放入適當的對象中。我想創建我的對象的數組並編輯我的對象的屬性。它在目標C中對我更有意義。在asp.net中,我仍然不爲數據創建對象,我使用SQL Server存儲過程,因爲我有一個非常複雜的數據結構,並且想要完全控制我查詢的所有內容。

然而,需要AGES創建類來包裝你的表。在覈心數據中,只需單擊一下即可生成表示核心數據實體的類,因此,權衡是花費時間手動生成coredata模式,而不是手動生成類來表示數據表/實體/無論您更喜歡調用它們。

我在這裏選擇了核心數據。

,你可能會需要使用類別來擴展生成的類,但其實這是很容易,也很冷靜,

一個coredata的最大優勢是自動顯示在表視圖變化fetchedresults控制器。因爲我的應用程序有2到3個層次結構的表視圖 - 在視圖2中更改數據,然後返回到tableview,查看1並查看視圖1中的更新,而無需手動重新加載數據,這非常酷。

謂詞可以。他們具有足夠的理性,牢記,無論你提取什麼對象,都可以從這個對象中橫切關係 - 如果有時候有點混亂,它也很酷 - 這完全是從我覺得的sql思維的倒退方式。一旦你習慣了它,它足夠簡單並且足夠強大。這只是一個位在第一

NSManaged對象(任何對象要存儲在覈心數據)怪異及其subclasss有自己managedobjectcontext - 即self.managedObjectContext決策是一件輕而易舉的事明確地保存任何變化,即:

[email protected]"james" 
[email protected]"blue" 

NSError * error; 
if ([self.managedObjectContext save:&error]) { 
    NSLog(@"saved"); 
} 

它比建立sqlite連接,命令和執行它們要乾淨得多。

核心數據API比SQLite API(很好,它是c)更清潔。

猜想我是一個轉換!

+0

我不知道爲什麼這是-1'd?我很抱歉,但如何閱讀2本書300多頁專門coredata書頁不構成研究?我讀到的內容很短,只涉及簡單的例子,而不是我想要實現的內容,這更復雜。社區是問問題,他們不是?說我沒有試圖找到我自己是非常不公平的。如果我能找到一個符合我需求的示範演示或優秀文章,我不會花時間打字問題嗎? – 2013-03-15 08:58:38

+0

完全同意你的看法。好問題,我也對這個答覆感興趣。 – 2013-03-17 12:45:12

+0

FMDB(https://github.com/ccgus/fmdb)是一個很好的用於sqlite的Objective-C接口。隨着DAO模式,它可以提供非常整潔的代碼。如果您需要細粒度的控制,如事務回滾/提交,自定義SQL等,可能是一個不錯的選擇。 – 2013-12-29 14:37:30

回答

4

首先(你可能聽說過):核心數據不是數據庫。它是一個「具有生命週期,搜索和持久性功能的對象圖管理器」,本文描述的差異比我所能做的更好:http://www.cocoawithlove.com/2010/02/differences-between-core-data-and.html

另請參閱Use CoreData or SQLite on iPhone?及其中的鏈接,以獲取可能有所幫助的更多信息。

我們您的具體問題:

一)建立時間 - 有從現有的數據庫模式創建coredata數據映射 (SQL服務器,SQLite的或腳本)

的方式

不可以。您必須先創建一個核心數據「模型」(使用Xcode模型編輯器)。模型由具有與其他實體的屬性和關係的實體組成。核心數據具有「持久存儲」,可以是SQLite文件(也可以是「內存存儲」)。 Core Data使用的模式和表格沒有正式記錄。 你可能嘗試直接創建SQLite核心數據存儲(格式不太複雜),但從SQLite遷移到核心數據的最簡單方法可能是編寫自己的代碼來讀取SQLite表並創建相應的核心數據對象。

b)如果我有一個表中的幾千行(這是在作業上使用的庫存 項目列表)。我的理解是,coredata 檢索該對象的所有項目,然後使用 謂詞篩選它們。這究竟是如何運作的,還是我誤解了?如果它的行爲如此有效,這是否有效?

您的理解不正確。核心數據使用「提取請求」來提取數據,可選地通過「謂詞」進行過濾並按「排序描述符」進行排序。對於基於SQLite的存儲,該提取請求將轉換爲SQL查詢並在SQLite級別上執行。 (這對可能的謂詞施加了限制,並不是所有的SQL查詢都可以通過獲取請求獲得。) 只有獲取的對象被加載到內存中。

C)雖然我已經夷爲平地結構儘可能有 仍然可能是一個需要我加入3或4表一起 - 核心 數據是使用像這樣高效的關係?

是的。

...沒有核心數據提供了sqllite任何優勢,爲消費 休息服務或JSON來從服務器獲取數據,並把傳輸 完成細節回服務器?

也許看看RestKit,它具有核心數據支持。但我對此並不熟悉,所以我無法提供關於這個問題的更多信息。

+0

感謝您的答案,抱歉沒有回覆,因爲我沒有看到它。一個很好的答案 - 我將以SQL Server/ASP.net開發人員的身份添加自己的經驗。 – 2013-04-23 13:10:41