So, basically we have surveys which all share the same structure (collections, properties, etc) but the data can be different.... My idea would be to store all in one table and create a column which separates templates from conducted ones.
Okay, what you're talking about is a prototype. The "template" survey is a prototype. Clearly, if a prototype has exactly the same structure as an instance based on the prototype, if would be foolish and wasteful to create entirely different tables for the same structure -- all the more so when you realize that that means any change in that structure has to mirrored in both sets.
Would I add a column to distinguish a prototype/template from a conducted survey? No, probably not. Instead I'd add another table, with a one-to-one relation to the root survey table. In this table, I'd add the little bit of metadata that does distinguish a prototype from a non-prototype.
For three reasons: 1) in any reasonable system, the prototypes will be a small minority of total surveys. 2) I'd often want to list all prototypes, in e.g. a "create new survey wizard" that lists a choice of protoypes on which to base the new survey. And 3) to hold that little bit of extra data:
create table survey_prototype (
id int not null primary key,
survey_id references survey(id) -- the regular survey table
wizard_description varchar(80)
. . . .
);
Now, I imagine that survey also has a description, but that for a prototype, that description is something like "REPLACE ME THIS IS THE DESCRIPTION THE USER WILL SEE" but that wizard_description is something like "A prototype political poll".
Now, since any lookup of a prototype/template has no chance of returning a conducted survey (since n o conducted survey joins to survey_prototype), your getMaster looks (conceptually, presumably you use an ORM) like this:
ConductedSurvey : Survey {
//gets the master according to the name
GetMaster() { "select * from survey_prototype join survey..."
}
Important: A Survey has a lot of relationships to other classes. If we decide to subclass. Should all of them be subclassed (cause we would copy the data from master for each object)?
You are correct: for any prototype you retrieve through your ORM, you'll have to deep copy it to save a new survey rather than overwriting the prototype. Since you have to do the deep copy anyway, in the deep copy you can instead of coying the base class that prototype uses, make a subclass copy.
Of course you'll have to make that decision at each level of the hierarchy; it would be nice to encapsulate each transformation policy for a deep copy transform in one class. Visitor Pattern will do this, as it has one overloaded visit function per (base) class of your types: so (at least) visitSurvey, visitQuestion, visitAnswer.
Since you'll be dealing with a tree (rooted at survey, with children questions and grandchild answers,i.e, Composite Pattern), I suggest you use the Visitor Pattern in your copy/transformer. Since your classes are relatively stable, visitor will work well. And it allows you to have multiple different concrete visitors, one for each type of transformation (and when it comes time to display or score a survey, you can write a visitor for that too -- so you'll get that functionality almost "for free" once you set up Visitor Pattern).
To handle subclassing in the database, you can use any one of the common nhibernate patterns for this; that way, once you've visited and transformed, you'll have a new non-prototype survey tree that can be saved to the database 'automagically by nhibernate.
So to sum up: survey_prototype table, get a prototype, nhibernate will retrieve the whole tree when you ask for the root at survey_prototype, visit that tree with a deep copying transformer which returns the copied root, let the user write on that, save the copied root and let nhibernate recursively save every node of the tree. When the user needs to see the non-prototype survey, pull the root from survey with nhibernate, use the display visitor to display it, etc.