Two stage data editing in database

For the purpose of the question, let's imagine that I have a blogging application which consists of blogs and blog sub-entries related to the blog. My data i开发者_如何学运维s stored in a database in two separate tables: Blog and BlobSubEntries and I have a foreign key in BlogSubEntries on Blog. Both of these tables contain data that can be edited.

Now my web site query this database to display the blogs. I also have a cms to edit the blog entries. I don't want to put a save button in the cms so I want to send every edits to the server but don't want this data to be available to the web site before the blogger actually decides to publish the work.

Here's some things to consider:

• I don't want to have millions of queries on the database.
• I want the old data to be available during the edits.
• I'm using django with a relational database

After this lengthy intro, here are my questions:

• How would you handle this two step staging of data(consider the fact that there's two models related to each other)?
• What if I wanted to evolve this staging process into versioning ?
• I've recently read some on CouchDB, would a document database simplify this kind of problem ? If so how ?

Thanks for your time.

A quick answer would be to have a model like:

[Blog]<-----[BlogSubEntries]<----[SubEntryDraft]
   ^        (current content)    |-------------|
   |                             |draft_content|
   |                             |-------------|
[BlogDraft]
(draft content)

If you want to do versioning, then you would have something like:

[entry]-(1)-------(N)-[entry_version]
                      |-------------|
                      | version_num |
                      | content     |
                      |-------------|

I don't think a document-storage engine would make much difference. You would still need to keep track of which version of content belongs to a given entry (or blog, or whatever). Unless, of course, the system you used already provided versioning.

Now that I think about it, you could also do it in one single table:

[  BlogSubEntry  ]
|----------------|
| content        |
| entry_id       | <--| composite alternate key:
| version_num    |    | UNIQUE(entry_id, version_num) NOT NULL
| surrogate_key  | <-- PRIMARY KEY
|----------------|