Давайте предположим, что у меня есть приложение о кулинарных рецептах с двумя основными функциями:

Первый включает в себя ТЕКУЩИЙ рецепт, который я готовлюВторой хранит рецепты, которые я решил сохранить

СТАНДАРТНЫЙ СЦЕНАРИЙ

Мой текущий рецепт "Чизкейк" и вRecipeDetailViewController Я вижу текущие ингредиенты, которые я добавил для этого рецепта:

сахарМолокоМасло сливочноеи т.п.

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

* нажмите сохранить *

Рецепт теперь сохранен (теперь зарегистрирован) и вRecipesHistoryViewController Я вижу что-то вроде этого:

15 ноября 2013 г. - Чизкейк11 ноября 2013 г. - Браунии т.п.

Теперь, если я хочу, я могуредактировать рецепт вистория и измените молоко на соевое молоко, например.

Проблема в том, что редактирование рецепта в историиНЕ СЛЕДУЕТ отредактируйте рецепт (и его ингредиенты) в моем текущем рецепте и наоборот. Если я редактирую текущий рецепт и заменяю масло арахисовым маслом, оно не должно редактировать ни одного рецепта, хранящегося в истории. Надеюсь, я объяснил себе.

ПОСЛЕДСТВИЯ

Что подразумевает этот сценарий? Подразумевается, что в настоящее время для удовлетворения функции этих функций я дублирую рецепт и все подчиненные отношения (ингредиенты) каждый раз, когда пользователь нажимает кнопку «Сохранить рецепт». Ну, это работает, но я чувствую, что это может быть что-то более чистое. С этой реализацией оказывается, что у меня есть TONS различных дубликатов Core Data объекта (строк sqlite), например:

Объект № 1, название: масло, рецепт: 1Объект № 2, название: масло, рецепт: 4Объект № 3, название: масло, рецепт: 3

и т.п.

Идеи? Как я могу оптимизировать эту модель структуры?

РЕДАКТИРОВАТЬ 1

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

РЕДАКТИРОВАТЬ 2

В настоящее времяRecipeHistory объект содержит это:

+-- RecipeHistory --+
|                   |
| attributes:       |
| - date            |
+-------------------+
| relationships:    |
| - recipes         |
+-------------------+

+----- Recipe ------+
| relationships:    |
| - recipeInfo      |
| - recipeshistory  |
| - ingredients     |
+-------------------+

+-- RecipeInfo  ----+
|                   |
| attributes:       |
| - name            |
+-------------------+

+--- Ingredient ----+
|                   |
| attributes:       |
| - name            |
+-------------------+
| relationships:    |
| - recipe          |
+-------------------+

paulrehkugler верно, когда он говорит, что дублирование каждогоRecipe объект (и его отношения RecipeInfo и Ingredients), когда я создаюRecipeHistory собирается заполнить базу данных тоннами данных, но я не нахожу другого решения, которое позволило бы мне гибкость в будущем. Возможно, в будущем я хотел бы создать статистику о рецептах и истории, и наличие объектов Core Data может оказаться полезным. Как вы думаете? Я думаю, что это распространенный сценарий во многих приложениях, которые хранят историю и позволяют редактировать элементы истории.

БОЛЬШОЕ ОБНОВЛЕНИЕ

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

Сказал это, я хочу объяснить, что приложениеПОТРЕБНОСТИ два раздела: - первый: где я могу увидеть рецепт ТЕКУЩЕГО со связанными ингредиентами - второй: где я могу увидеть рецепт, который я решил сохранить, нажав кнопку «Сохранить рецепт» в первом разделе

Текущий рецепт, найденный в первом разделе, и рецепт Х, найденный в разделе «история», не имеют НИЧЕГО общего. Однако пользователь может редактировать любые рецепты, сохраненные в разделе «история» (он может редактировать название, ингредиенты, что угодно, он может полностью редактировать все, что касается рецепта, найденного в разделе истории).

Это причина, почему я придумала, дублируя всеNSManagedObjects. Однако, таким образом, база данных будет расти как сумасшедшая, потому что каждый раз, когда пользователь сохраняет текущий рецепт, объект, представляющий рецепт (Recipe), а также отношения, которые были у рецептов (ингредиенты). Так, например, будет множество ингредиентов под названием «Масло». Вы можете сказать мне: зачем, черт возьми, вам нужны ТОННЫ предметов из «Масла»? Ну, мне это нужно, потому что ингредиенты имеют, например, атрибут «количество», поэтому в каждом рецепте есть ингредиенты с разным количеством.

Во всяком случае, мне не нравится этот подход, даже он кажется единственным. Спросите меня, что вы хотите, и я постараюсь объяснить каждую деталь.

PS: извините за мой базовый английский.

РЕДАКТИРОВАТЬ