Data Base Design Dilemma

I am creating a simple DB application for reports. According to DB design theory, you should never store the same information twice. This makes sense for most DB applications, but I need something that you can simply select a generic topic, you could then keep the new instance copy of the generic topic untouched or change the information but the generic topic should not be modified by modifying the instance copy, but the re开发者_运维技巧lationship needs to be tracked between the original topic and the instance copy of the topic.

Confusing, I know. Here is a diagram that may help:

I need the report to be immutable or mutable based off of the situation.

A quick example would be you select a customer, then you finish your report. A month later the customer's phone number changes so you update the customer portion of the DB, but you do not want to pull up a finished report and have the new information update into the already completed report.

What would be the most elegant solution to this scenario?

This may work:

But by utilizing this approach I would find myself using looping statements and if statements to identify the relationships between Generic, Checked Off and 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];
        }            
    }
}

I know a better solution exists, but I cannot see it.

Thank you for time.

It's tricky to be very precise without knowing much about what exactly you're modelling, but here goes...

As you've noted, there's at least two strategies to get the "mutable instance copies of a prototype" functionality you want:

1) When creating an instance based on a prototype, completely copy the instance data from the prototype. No link between them thereafter.

PRO: faster access to the instance data with less logic involved.

CON 1: Any update to your prototype will not make it into the instances. e.g. if you have the address of a company wrong in the prototype.

CON 2: you're duplicating database data -- to a certain extent -- wasteful if you have huge records.

2) When creating an instance based on a prototype, store a reference to the 'parent' record, i.e. the prototype, and then only store updated fields in the actual instance.

PRO 1: Updates to prototype get reflected in all instances.

PRO 2: More efficient use of storage space (less duplication of data)

CON: more logic around pulling an instance from the database.

In summary: there's not any magical solution I can think of that gets you the best of both of these worlds. They're both valid strategies, depending on your exact problem and constraints (runtime speed versus storage size, for example).

If you go for 2), I certainly don't think it's a disaster -- particularly if you model things well and find out the best most efficient way to structure things in core data.