I've several models whose records AND associations might have two states that must definitely be endured. Final, and Draft.

Here's a bit more detail: When the model is "application" and also the user submits your final application, then I have to store and have the ability to retrieve that final application.

If, later on, the consumer really wants to modify that 'application form', then they have to edit a draft copy of this final record until he submits a brand new final version. That's, he cannot edit the prior final application until he inspections the "final" box, after which the draft becomes the brand new final version.

The issue is the fact that both final and draft have associations should be saved using their related records. That's, their related records (e.g. a credit card applicatoin has numerous contact persons) should be saved inside a manner that's retrievable in the final and also the draft versions without confounding a 'final' contact along with a 'draft' contact.

Presently I'm able to think about two methods to solve this issue:

  • Use ActsAsAudited and audit just the final records. Querying for that finals whenever I want them. (There is a fork of ActsAsAudited which tracks associations). Then query the Audit tables for that latest records.
  • Use two parallel data table sets: One which keeps the drafts, and the other that keeps just the final copies.

I Believe keeping the finals and drafts within the same table might duplicate the objective of individuals tables, and render the dwelling harder to follow along with.

Are you aware associated with a other schema or strategy that will handle the issue more stylishly? Or that will reduce code complexity?

Here is a similar question that wound up while using second item above:

http://stackoverflow.com/questions/629873/draft-version-of-database-table

Bernie

The issue is the fact that both final and draft have associations that must definitely be stored synchronized

Just how can your final version change, ever? Final versions ought to be immutable.

Would you imply that someone might draft and submit a document although other customers are earning drafts?

If that's the case, source control appears relevant. A wiki-method for merging documents could be helpful, or perhaps a simple 'locking' principle to ensure that two customers cannot conflict.

For storing a versioned document, should you discount while using file system and wish to make use of a conventional database, there are 2 primary approaches:

  1. place it all in one table, having a flag for draftfinal, along with a flag for that 'head' - the newest final version of every document

  2. three tables: a table from the 'heads', another table of drafts along with a third table using the historic final versions

The benefit of one approach within the other is going to be performance and distribution when the system will get really large.

But when the machine is small, I'd advocate the very first approach - just one table - possibly using the finesse of three 'views' in order to make migration up to the more complicated three-table approach less painful in version 5..