Мысли о модели данных

Question

Для моего приложения я подумал о двух разных моделях данных, но я не вижу, какая из них будет лучшей как по производительности, так и по размеру файлов.В моем приложении я должен хранить рецепты, которые будут состоять из массива с ингредиентами, массива с инструкциями, массива с советами и некоторыми свойствами для выбора некоторых рецептов (например, рейтинг, тип блюда).

Я думал о двух разных моделях.Первым было бы преобразовать массивы в NSData и сохранить их все в модели Core Data.Поскольку массивы локализованы, это означает, что там будет несколько массивов одного и того же вида (например, инструкции EN, инструкции FR, инструкция NL).Поскольку нет необходимости запрашивать массивы, я доволен тем фактом, что мне нужно преобразовать массивы в NSData.

Другая модель - это базовые данные, которые содержат только свойства для фильтрации рецепта,и идентификатор файла .plist, который хранится в основном комплекте или каталоге документов (так как некоторые из этих файлов будут созданы нами, а некоторые - пользователем).Этот файл .plist будет содержать все инструкции, ингредиенты и т. Д. Опять же, существует несколько массивов одного и того же типа для разных локализаций.

Я надеюсь, что вы можете помочь мне принять решение о том, какой из этих вариантов будет наилучшимс точки зрения производительности и дискового пространства.Я также был бы признателен, если бы вы могли придумать другое решение.

Answer 1

Если вы собираетесь использовать Core Data, вам, как правило, следует идти до конца. В этом случае у вас будет NSManagedObject Ingredient. Я бы, вероятно, поместил в Ingredient такой метод, как stringValueForLocale:, который позаботился бы о возвращении мне наилучшего значения. Это означает, что данный ингредиент можно перевести один раз и использовать для всех рецептов.

В таком случае у вас будет компонент "Компонент", который будет иметь Ингредиент, количественное значение и единицу. Рецепт будет иметь свойство 1: M components, которое будет указывать на них. Component, скорее всего, также должен иметь englishDescription, который будет возвращать значение для печати, такое как "1 / 4c sugar", тогда как frenchDescription может печатать "50g de sucre" (обратите внимание, что конверсия объем / масса там; компонент, вероятно, где ты справишься.)

Инструкции немного отличаются, так как они с меньшей вероятностью могут быть использованы повторно. Я думаю, вам может повезти и «взбить яйца до твердых пиков». может появиться в нескольких рецептах, но если вы не собираетесь активно искать эти виды повторного использования, это, вероятно, больше проблем, чем стоит. Инструкции также являются естественным местом для решения культурных различий. Во Франции яйца часто хранят при комнатной температуре. В Америке они всегда в холодильнике. Чтобы правильно перевести французский рецепт на американский английский, иногда нужно включить дополнительный шаг, например «довести яйца до комнатной температуры». (Но это зависит от рецепта, поскольку это не всегда имеет значение.) Обычно имеет смысл делать это в инструкциях, а не в ингредиентах.

Вероятно, я бы создал Instructions сущность с stringValuesForLocale: (которая возвращала бы массив строк). Затем вы могли бы выполнить некоторое профилирование и решить, следует ли разбить это на отдельные LocalizedInstructions сущности, чтобы вам не приходилось ошибаться во всей локализации. Преимущество этого дизайна в том, что вы можете позже передумать о внутренней структуре базы данных, и это не влияет на более высокие уровни. В любом случае, однако, я бы, вероятно, сохранил фактические инструкции как NSData, кодирующий NSArray. Вероятно, это не стоит хлопот и затрат на создание группы отдельных LocalizedInstruction сущностей.