1

iOS 用にローカライズされたスキーマに取り組んでいます。翻訳されたフィールドを持つことができるさまざまなエンティティがあるため、それぞれに対してTranslationエンティティを作成します。2 つのエンティティーの間には常に 1 対多の関係があり、将来的に新しい言語を追加できるようになり、Entity.translationsを介して翻訳にアクセスできます。ここまでは順調ですね。

Entity
EntityTranslation

1) まず、そのようなアプローチが良いかどうか知りたいです。純粋な SQL 環境で使用するソリューションなので、その道をたどることができると思います。

Entity.text2）それから...私は（経由で）ユーザーに適切なテキストを表示するために使用したいと思いますNSLocale preferredLanguages。translations戻り値としてNSSet、エンティティ モデルに属性を手動で追加し、ゲッターを変更するという 1 つのオプションがあります。

// Entity.h
@property (nonatomic, retain) NSString * text;

// Entity.m
@synthesize text;

- (NSString *) text
{
  NSString *locale = [[NSLocale preferredLanguages] objectAtIndex:0];

  NSSet *filteredTranslations = [self.translations filteredSetUsingPredicate: [NSPredicate predicateWithFormat:@"locale = %@", locale]];
  EntityTranslation *translation = [[filteredTranslations allObjects] objectAtIndex:0];

  return translation.text;
}

それは機能しますが、意味がありますか？パフォーマンスの問題はありますか? Fetched propertiesを使用して同様のことを行うことは可能ですか? 可能であるとのことですが、Xcode Core Dataエディターを使用して機能させることはできません...

ありがとう。

4

1 に答える 1

2

パフォーマンスの問題が発生するかどうかは、データベースの大きさと値を取得する頻度によって異なります。Instruments を介してコードを実行し、コストがかかる CPU 時間の割合を確認し、必要に応じてキャッシュする必要があります。

私が行う微調整の 1 つは、NSPredicate オブジェクトを静的変数に格納することです。これは、頻繁に変更されることはないためです。

テーブルに多くのレコードがない場合は、レコード セット全体を一度取得してから、いつでも検索できる NDDictionary に保存するのが最善です。

ただし、非常に単純な問題 (キー値の検索) を解決するために、大きく複雑なシステム (オブジェクト指向ラッパーを備えたリレーショナル データベース) を使用するという間違いを犯していると思います。また、複雑なソリューションは、ほとんどの場合、単純なソリューションよりも遅く、メモリを大量に消費します。

ローカリゼーションを行うには .strings ファイルを使用することをお勧めしますが、代わりにコア データを使用する利点は思いつきません。200MB のローカライズされたテキストがありますか? そうでない場合は、コア データの代わりに .strings ファイルを使用する方がよいと思います。

于 2011-11-28T19:55:45.063 に答える