在核心數據中存儲上下文屬性的最佳方法？

Question

我正在使用Core Data來存儲對象。 對我來說最有效的可能性（即最佳執行效率，最少代碼，最簡單和與現有函數/庫/框架的最大兼容性），根據上下文為每個對象存儲不同的屬性值，知道上下文不能是預定義，將由軍團和不斷編輯的用戶？

例：

對象是一個人（潛在=雇主/ =雇員）

每個人都為其他幾個人工作，並且與他們的工作關系有不同的頭銜，他們的頭銜可能會從一年變為另一年（如果這個細節很重要：每個人也可能同時雇用一個或幾個其他人，這就是為什么一個人是雇員，但也可能是雇主）

所以我的對象的一個​​屬性是“Title vs Employer vs Year Ended”

我能用現有知識做的最好的事情是將所有三個元素一起保存為一個字符串，該字符串將是分配給每個對象的屬性值，並且不斷解析該字符串以便能夠使用它，但這具有以下（巨大的）缺點：

（1）執行速度過慢，能源使用增加。 使用這個上下文屬性是我預期的App核心功能的核心（所以它實際上每分鍾使用10-100次）。 必須不斷解析這些信息以便能夠使用它增加了我不得不避免的過度處理（2）不正確的編碼開銷。 將此上下文屬性保存為字符串將在每次我使用此中心信息時（通常非常頻繁地）為我提供額外的編碼。 （3）不合理的復雜性和潛在的不相容性。 它還會增加不必要的復雜性，並且脫離預期的做法，它將逃脫Core Data的優勢。

沒有上述缺點，實現我的預期目的的最有效方法是什么？

Answer 1

以你的例子，一個選擇是創建一個Employment實體，與屬性title和yearEnded和兩個（一對一）關系到Person 。 一種關系代表employer ，另一種代表employee 。

兩種情況下的反比關系都很多。 一個代表雇員是雇員的雇員（因此你可以將雇員命名為employmentsTaken ），而另一個代表就是雇員是雇主的雇佣關系（所以你可以將其命名為employmentsGiven ）。

概括，這是Apple推薦的許多具有屬性的關系的解決方案（參見文檔中的 “基於其語義建立關系”）。

這是否會解決您問題中列出的所有問題，我將繼續您的實驗：如果事情每分鍾改變10-100次，則獲取請求和創建/更新/刪除中間（ Employment ）實體的開銷可能會更糟比你的字符串表示。