Дилемма проектирования баз данных

Question

Я создаю простое приложение БД для отчетов. Согласно теории проектирования БД, вы никогда не должны хранить одну и ту же информацию дважды. Это имеет смысл для большинства приложений БД, но мне нужно что-то, что вы можете просто выбрать общую тему, затем вы можете оставить копию нового экземпляра общей темы нетронутой или изменить информацию, но общую тему не следует изменять путем изменения экземпляра. копировать, но необходимо отслеживать взаимосвязь между исходной темой и экземпляром темы.

Смущает, я знаю. Вот диаграмма, которая может помочь:

Мне нужно, чтобы отчет был неизменным или изменяемым в зависимости от ситуации.

Быстрый пример: вы выбираете клиента, а затем заканчиваете свой отчет. Месяц спустя телефонный номер клиента изменяется, поэтому вы обновляете клиентскую часть БД, но вы не хотите получать готовый отчет и обновлять новую информацию в уже заполненном отчете.

Что было бы наиболее элегантным решением для этого сценария?

Это может работать:

Но, используя этот подход, я обнаружил бы, что использую циклические операторы и операторы if для определения взаимосвязей между Generic, Checked Off и Report.

for (NSManagedObject *managedObject in checkedOffTaskObjects) {
    if ([[reportObject valueForKeyPath:@"tasks"] containsObject:managedObject]) {
        if ([[managedObject valueForKeyPath:@"tasks"] containsObject:genericTaskObjectAtIndexPath]) {
            cell.backgroundView = [[[UIImageView alloc] initWithImage:[UIImage imageNamed:@"cellbackground.png"]] autorelease];
        }            
    }
}

Я знаю, что существует лучшее решение, но не вижу его.

Спасибо, что уделили время.

Answer 1

Сложно быть очень точным, не зная много о том, что именно вы моделируете, но здесь все идет ...

Как вы заметили, есть как минимум две стратегии для получения "изменяемых копий экземпляра"требуемой функциональности прототипа:

1) При создании экземпляра на основе прототипа полностью скопируйте данные экземпляра из прототипа.После этого между ними не будет связи.

PRO: более быстрый доступ к данным экземпляра с меньшим количеством логики.

CON 1: Любое обновление вашего прототипа не попадет в экземпляры.например, если у вас неверный адрес компании в прототипе.

CON 2: вы дублируете данные базы данных - в определенной степени - расточительно, если у вас огромные записи.

2) При создании экземпляра на основе прототипа сохраните ссылку на «родительскую» запись, т.е. прототип, а затем сохраняйте только обновленные поля в фактическом экземпляре.

PRO 1: Обновления прототипа отражаются во всех экземплярах.

PRO 2: Более эффективное использование пространства хранения (меньше дублирования данных)

CON: больше логики при извлечении экземпляра из базы данных.

В итоге: я не могу придумать волшебного решения, которое бы дало вам лучшее из обоих миров.Они обе являются действительными стратегиями, в зависимости от конкретной проблемы и ограничений (например, скорость выполнения в зависимости от объема хранилища).

Если вы выберете 2), я, конечно, не думаю, что это катастрофа - особенно если вы хорошо моделируете вещи и находите лучший и наиболее эффективный способ структурировать вещи в основных данных.