パブリッシュ/ドラフトテーブルを使用してSQLデータベースを設計するにはどうすればよいですか？

Question

私はブログのデータベースの仕組みを作る方法が不思議です。著者は記事を書いてブログに公開します。これは

著者、記事、ブログ

しかし、またドラフトを持つことができます記事のようなテーブルを持つ非常に単純です。ドラフトは読者には見られず、記事が公開されるとブログの読者が見ることができます。公開された記事は未公開で、ドラフトになります。

ドラフト

と

を接続する方法

は、記事やブログのテーブルと

テーブルを公開しますか？それは必要ですか？または、Articleテーブルに列を追加するだけでもいいですか？ IsPublishedのようなものか何か？

Answer 1

これを処理するにはいくつかの方法があります。 1つはコンテンツにstatusフラグを設定することです。これは単純なサイトに便利です。もう1つは、コンテンツをどこに、どのように、いつ表示するべきかを接続するジョイン・テーブルを持つことです。

単純なサイトの場合は、コンテンツテーブルにstatusフラグを追加するだけです。

create type statuses as enum ('published', 'draft'); 

create table posts (
    id serial, 
    author integer references people(id), 
    content text not null, 
    ...whatever other data... 
    status statuses default 'draft' 
); 

私はタイプミスが（重要）キャッチされますので、収納スペースを（それほど重要ではない）を低減するPostgreSQL enumerated typeを使用し、そのすべての可能な状況があるのではなく自分が追加されているかを確認するための場所がありますしましたウィリー・ニリー（また重要）。

次に、公開されている投稿をすべて選択することができます。

select * 
from posts 
where author = ? and 
     status = 'published' 

これは非常に簡単ですが、ディスプレイとコンテンツは一緒に使用されます。 statusフラグをチェックするのを忘れた場合、投稿の下書きが表示されます。

---

statusフラグのバリエーションは、「公開日」を持つことです。この前は表示されません。この時間が過ぎると、それが行われます。

create table posts (
    id serial, 
    author integer references people(id), 
    content text not null, 
    ...whatever other data... 
    publish_at datetime default '9999-12-31' 
); 

次に、あなたはpublish_atが現在の日時よりも小さい場合、それは見て表示するかどうかを確認することができます。

​​

デフォルトで '9999-12-31'に設定すると、デフォルトですべての投稿が公開されなくなります。これは公開/草案と、余分なコードを実行することなく自動的に投稿を公開する機能とを組み合わせたものです。

---

もっと堅牢なソリューションは、公開するものとその場所の結合テーブルを用意することです。同じpostsテーブルから開始しますが、statusカラムは使用しないでください。

create table posts (
    id serial, 
    author integer references people(id), 
    content text not null, 
    ...whatever other data... 
); 

人のブログには1つ以上あります。

​​

次に、ブログ記事と投稿をつなぐ結合テーブルを作成します。何かが「公表」される今

create table blog_posts (
    blog integer references blogs(id), 
    post integer references posts(id), 
    posted datetime not null default current_timestamp 
); 

は、それはblog_postsに挿入されています。ステータスフラグはありません。あなたは、ユーザーのブログ記事を参照したい場合は...

select * 
from blog_posts 
join blogs on blogs.id = blog_posts.blog 
where blogs.curator = ? 
order by posted desc; 

ここでの利点は、1つのポストがよりblog_postsテーブルにテーブルまたは複数のフィールドを追加することによって、参加する複数の場所に現れることがあります。そして、すべてのステートメントに含めることを覚えておくフィールドは、statusです。どちらかが結合テーブルにあるか、結合テーブルにありません。

blog_postsは、publish_atフィールドを持つこともできます。

Answer 2

この使用して、それを可視化： "記事" テーブルの上に

著者について基本的にすべての情報

：

"著者" テーブルの上に

を

各記事には1人の著者がいる（一般的には...うーんだが、複数の可能性もあるが、これは行うだろう）。外部キーauthors_id。公開されたとドラフトについては

：

"公表" と "ドラフトは、" ステータス・フィールドです。この場合はenum（ 'published'、 'draft'）です。あなたのisPublishedで？私はブール値（すなわち、はい/いいえ、真/偽）を持つDBデザインに対して何も持っていませんが、あなたが列挙型としてそれを持っているなら、より明確になります。おそらく後で別のステータスが追加され、isPublishedはもはや関連性がありません。次のような場合があります。後で「スケジュールされた公開」とか「スケジュールされた公開解除」とか他のステータスと言うステータスが必要です。 「ブログ」テーブルにつきましては

：あなたは必ずしも必要としない

その1つのだけのブログを持っている場合。しかし、あなたはいくつかのブログを持っている場合は、そのテーブルが必要です。上記のSQLのよう

：

CREATE TABLE IF NOT EXISTS `authors` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, 
    `name` VARCHAR(200) NULL, 
    `status` ENUM('active', 'inactive') NULL, 
    PRIMARY KEY (`id`)) 
ENGINE = InnoDB 

CREATE TABLE IF NOT EXISTS `articles` (
    `id` INT UNSIGNED NOT NULL AUTO_INCREMENT, 
    `title` VARCHAR(60) NULL, 
    `content` TEXT NULL, 
    `status` ENUM('published', 'draft') NULL, 
    `datetime` INT NULL, 
    `authors_id` INT UNSIGNED NOT NULL, 
    PRIMARY KEY (`id`), 
    INDEX `fk_articles_authors_idx` (`authors_id` ASC), 
    CONSTRAINT `fk_articles_authors` 
    FOREIGN KEY (`authors_id`) 
    REFERENCES `authors` (`id`) 
    ON DELETE NO ACTION 
    ON UPDATE NO ACTION) 
ENGINE = InnoDB