データモデルに関する考え方

Question

私のアプリケーションでは、2つの異なるデータモデルが考えられましたが、パフォーマンスとファイルサイズのどちらが最適かはわかりません。私のアプリでは、レシピを保存する必要があります。レシピは、成分を含む配列、命令付きの配列、ヒントを持つ配列、レシピを選択するためのプロパティ（レーティング、料理の種類など）で構成されます。

私は2つの異なるモデルを考えました。最初は、配列をNSDataに変換してコアデータモデルにすべて格納することです。配列はローカライズされているので、同じ種類の配列が複数存在することを意味します（たとえば、instructionsEN、instructionsFR、instructionsNL）。配列を照会する必要はないので、配列をNSDataに変換しなければならないという事実に満足しています。

もう1つのモデルは、レシピをフィルタリングするためのプロパティと、メインバンドルまたはドキュメントディレクトリに保存されている.plistファイルの識別子のみを含むコアデータです（これらのファイルのいくつかは作成されるため私たちによって、そしていくつかはユーザーによって作成されます）。この.plistファイルには、すべての命令、成分などが含まれます。同じ種類の複数の配列が、異なるローカライゼーションに存在します。

私はこれらのオプションのどれがパフォーマンスとディスクスペースの面で最適なのかを自分の判断で助けてくれることを願っています。あなたが別の解決方法を考えることができたら、私はそれを感謝するでしょう。

Answer 1

コアデータに行く場合は、一般的にすべての方法を実行する必要があります。その場合は、NSManagedObject Ingredientを使用します。私はおそらくstringValueForLocale:のような成分を、私に最高の価値を返すようにする方法をつけるでしょう。これは、特定の成分が一度翻訳され、すべてのレシピで再利用可能であることを意味します。

あなたは、成分、量値、単位を持つ成分エンティティを持っています。レシピには1：Mのプロパティcomponentsがあり、これを指しています。 ComponentにはenglishDescriptionもあるはずですが、frenchDescriptionは「1/4c砂糖」のような印刷可能な値を返しますが、「50g de sucre」は印刷されます（ボリューム/マスの変換に注意してください。 ）

説明書は再利用可能性が低いため、少し異なります。私はあなたが幸運になるかもしれないと思うし、 "ビートの卵を堅いピークに。いくつかのレシピで表示されるかもしれませんが、これらの種類の再利用を積極的に探すつもりがない限り、おそらくそれは価値があるよりも面倒です。指示はまた、文化的相違に対処する自然な場所です。フランスでは、卵は室温で貯蔵されることが多い。アメリカでは、彼らは常に冷蔵されています。フランスのレシピをアメリカ英語に正しく翻訳するには、「卵を室温に持っていく」のような余分なステップを追加する必要があることがあります。 （ただし、それはレシピに依存しますので、必ずしも問題ではありません）。一般的に、これは成分ではなく説明書で行います。

おそらくstringValuesForLocale:（これは文字列の配列を返す）でInstructionsエンティティを作成します。次に、いくつかのプロファイリングを行い、これを別のLocalizedInstructionsエンティティに分割するかどうかを決めることで、すべてのローカライゼーションに不具合を起こす必要がなくなりました。この設計の利点は、後で内部データベースのレイアウトについて気にすることができ、より高いレベルに影響を与えないことです。どちらの場合でも、私は実際にNSArrayをエンコードするNSDataとして実際の命令を格納するでしょう。多分個々のものを作ることの手間とコストがかかりません。LocalizedInstructionエンティティ。