ドラフト/ライブコンテンツシステムのデータベース設計

Question

私はプロジェクトに取り組んできました

アーティクルが発行されたときに外部キーを変更したり、ドラフトテーブルからライブテーブルに内容をコピーするほうがよい場合は、

提案がありますか？

編集：公開バージョンは公開されている唯一のものですが、ドラフト版とライブ版は同時に存在します。ドラフトは1つとライブテーブルは1つしかありません

このデザインの理由の1つは、ライブに行く前にユーザーに記事の承認を強制することです。

更新：

我々は若干の修正とKierenのソリューションを使用することにしました。 IsPublished IsLiveのような項目に列を使用する代わりに、単一の状態列を使用することに決めました。さもなければデザインは同じままであった。ライブその後、「公表」されているとなっ

Answer 1

ドラフト記事

はいつもの事はarticleテーブルの上に、ステータス/タイプフラグを持っているだろう - IsLive。

個別のテーブルを使用する必要はなく、冗長です。外部キーを変更してもあまり意味がありません。記事が有効かどうかは、ドラフトかライブかに関係なく考えてください。唯一の違いは、のほとんどののケースでは、ライブ記事を表示したいだけです。将来的には両方を表示したい場合もあります。最初は両方のライブとドラフトバージョンを持つ一品の面では、ライブ

なった後に編集して、新しいドラフト版を持っているかもしれない

記事 - 最も一般的なパターンは、マスターArticleエンティティを持っているだろう/ objectとし、それから来てArticleVersionと言う。 ArticleVersionは、IsLiveプロパティを持つことになります。さらには、Article自身がプロパティCurrentLiveVersionIdを持つことになります。そうすれば、生放送版とドラフト版があるかもしれませんが、通常はにArticleとそれにCurrentLiveVersionIdを加えるだけで、現在のライブ版を入手できます。

ArticleVersionテーブルを持つメリットには、記事の全履歴、変更履歴を保存できるという利点があります。必要に応じて以前のバージョンに戻すか、変更を確認することができます。すべてが非常に低い実装コストです。

この方法を明確にすることができるかどうかを教えてください。

Answer 2

あなたのデザインは私にとって適切です。新バージョンでは、ライブになると、私は希望：

1. UPDATE（旧）ドラフト記事を指すようにPublicContentキー。

2. DELETE以前は公開されていなかった論文です。

3. NULL DraftContentキーまたは、常にがArticleContentにドラフト版、INSERT新しい空のドラフトを有し、かつ、それにDraftContentキーを指すためにあなたのモデルを呼び出す場合。