2015-04-01 71 views
0

我正在設計一個使用核心數據結構的Objective-C中的應用程序。保存具有許多冗餘信息的對象(使用核心數據)

我有以下結構:

@interface classA : NSManagedObject 
@property(nonatomic, strong) someType1 * property1; 
.. 
@property(nonatomic, strong) someTypeN * propertyN; 
@property(nonatomic, strong) NSSet * children; 
@end 

@interface classB : classA 
@property (nonatomic, strong) classA * parent; 
@end 

我有以下特點:

1)CLASSA的每個對象將在ClassB的許多兒童。 (classB中的對象本身沒有孩子)。 2)此外,classB的大多數對象將與它們的父對象共享許多共同的屬性(例如,您可以認爲在大多數情況下,只有屬性1在classB的對象和其父對象中的相同屬性之間纔會有所不同classA,因此對於classB中的x x.property2 = x.parent.property2等等)。

3)我只會通過對類型爲classA的對象的請求來查詢數據庫。

我正在尋找一種方法,通過只存儲類型爲classB的對象的必要屬性來減少我的應用程序的磁盤內存使用量。舉例來說,我可以保持CLASSB的對象設置爲nil的性質,除非它從其父的一個不同,定義CLASSB的吸氣劑:

- (sometypeX*) getPropertyX { 
    if (propertyX) return propertyX; 
    return parent.propertyX; 
} 

我的問題是: 1)我真的要去通過用零值而不是實際值填充我的數據庫來獲得磁盤內存 2)這樣的構造是否存在缺陷 3)是否有更好的方法/設計模式來處理這個問題?

在此先感謝您的幫助。

回答

0

我按照我問過的問題做了一些測試。

我測試了以下設置:我有11種NSString的性質和兒童CLASSB一個ClassA的。 classB是classA的一個子類,具有相同的屬性和父屬性。

我創建CLASSA的隨機之間100個1000個實例,其每一個在10名1000兒童CLASSB之間具有。對於classA的對象,我將每個字符串屬性設置爲隨機的10個字符的字符串。

我測試了兩個過程: - 要麼將對象A的子項的字段設置爲零 - 要麼將其設置爲其父屬性。

而且我監視了我的數據庫文件的大小。

不幸的是我無法從文件的增長速度提取線性規律(而這個作品只有一個班,我不能跟這更復雜父母/子女結構看着辦吧)。此外,我無法理解以.sqlite結尾的文件和以.sqlite-wal結尾的文件之間的大小重新分配。

然而,在所測試的所有制度(其中總分貝大小爲1 MB和MB 100之間)的我發現我使用第一過程相比於第二時獲得周圍的3倍。

因此,對於這個政權使用的未設置某些屬性似乎導致數據庫大小可以忽略不計的增益。

請告訴我,如果你要我更詳細地說明這個答案。

0

核心數據經過高度優化。它已經在使用錯誤來嘗試實施。從Faulting and Uniquing在文檔:

由於故障未實現的,一個管理對象故障消耗更少的存儲器,以及與一個故障管理對象不需要在內存中表示。

回答您的問題...

1)我是不是真的要填寫我與零值而不是實際值

數據庫如果你獲得任何與此內存來獲得內存方法,它可能是微不足道的。

2)是否有缺點,這種結構

它增加了許多複雜到你的代碼庫,沒有太多的理由。它使你的代碼更難閱讀,理解和維護。

3)是否有更好的方法/設計模式來解決這個問題

就在某種程度上這是很容易理解使用的核心數據,並讓它處理的優化,除非你有一個明確的,可衡量的需求進一步優化。

+0

爲了清楚我正在考慮磁盤內存(將所有對象存儲在數據庫中),而不是內存。我認爲你的答案涉及後一種情況? – vib 2015-04-01 15:39:43

+0

@ user3246191我不認爲*這種方法會爲您節省任何磁盤空間。 *在同一頁面上查看* uniquing *。核心數據不會創建重複記錄。一個例外是大的NSData對象可能被緩存在虛擬內存中(在你的應用程序的臨時目錄中)。在這種情況下,您應該自己將文件寫入磁盤,並將路徑存儲在Core Data中。 – 2015-04-01 15:45:26

+0

順便說一句,雖然我99%確定你的方法不會給你顯着的內存改進,但我不太確定磁盤空間的改進。您可能想要組合一個示例應用程序來衡量差異。 – 2015-04-01 15:46:41