Draft / Live Content System Database Design

Question

I've been working on a project that requires draft/live versions of content and have thought of a design such as below:

Article
    ID
    Creator
    CreationDate
    DraftContent(fk to ArticleContent)
    PublicContent(fk to ArticleContent)
    IsPendingApproval

ArticleContent
    Title
    Body

I am wondering if it would be better to change the foreign keys upon an article being published or if it is better to just copy the contents from the draft table to the live table.

Any suggestions?

Edit: Both draft and live versions exist at once although the live version is the only one that is visible to the public. There can only be one draft and one live table

Part of the reason for this design is to force users to have their articles approved before they go live.

Update:

We decided to use Kieren's solution with a slight modification. Instead of using a column for items like IsPublished IsLive we decided to use a single state column. Otherwise the design remained the same.

Answer 1

Draft articles that become live and then are 'published'

The usual thing would be to have a status/type flag on the article table - IsLive.

Using separate tables is unnecessary and redundant; changing foreign keys doesn't make much sense either. Think of the article as a valid object, whether its draft or live. The only difference is, in most cases you only want to display live articles. In some cases in the future, you might want to display both.

Articles that might be edited and have a new draft version after initially becoming live

In terms of one article having both a live and draft version - the most common pattern would be to have a master Article entity/object, and then say ArticleVersion coming from that. The ArticleVersion would have the IsLive property, or even better, the Article itself would have a property, CurrentLiveVersionId. That way there can be a live and draft versions lying around, but you'd only usually join Article onto the ArticleVersion by that CurrentLiveVersionId to get the current live version.

Advantages of having the ArticleVersion table include the fact that the entire history of an article, a changelog, can be stored, so you can revert to previous versions if needed, or review changes. All for a very low implementation cost..

Let me know if I can clarify this method.