Comment concevoir une base de données sql avec un tableau publish/draft?

Question

Je me demande comment faire un schéma de base de données de blog. Les auteurs rédigent des articles et les publient sur un blog. Ceci est assez simple avec les tables comme

Auteur, article, Blog

Mais l'article peut aussi avoir un projet. Le projet ne peut pas être vu par les lecteurs et quand l'article est publié, il peut être vu par les lecteurs du blog. L'article publié peut être non publié et devient un brouillon.

Comment connecter le

projet

et

publier

tables avec les articles et les tables de blog? Est-ce nécessaire? Ou peut-être juste ajouter quelques colonnes à la table article? Comme IsPublished ou quelque chose?

Answer 1

Il y a plusieurs façons de gérer cela. L'un est d'avoir un drapeau status sur votre contenu, ce qui est utile pour les sites simples. L'autre est d'avoir une table de jointure reliant le contenu à où, comment, et quand il devrait être affiché.

Pour les sites simples, vous pouvez ajouter un drapeau status à vos tableaux de contenu.

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' 
); 

Je l'ai utilisé un PostgreSQL enumerated type pour réduire l'espace de stockage (pas si important), donc les fautes de frappe seront pris (important), et donc il y a un endroit pour voir ce que tous les statuts possibles sont plutôt que de leur être ajoutés Willy nilly (aussi important).

Ensuite, vous pouvez simplement sélectionner tous les articles qui sont publiés.

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

Ceci est très simple, mais l'affichage et le contenu sont utilisés ensemble. Et si vous oubliez de vérifier le drapeau status, vous verrez les brouillons.

---

Une variation sur le drapeau status est d'avoir une date "à publier". Avant cette heure, il ne sera pas affiché. Après ce temps, il le fera.

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

Ensuite, vous pouvez vérifier si elle doit être affichée ou non en voyant si publish_at est inférieure à la datetime actuelle. Par défaut à '9999-12-31', tous les messages ne sont pas publiés. Par défaut, tous les messages sont non publiés. Cela combine publication/brouillon avec la possibilité de publier automatiquement un article sans avoir à exécuter de code supplémentaire.

---

Une solution plus robuste consiste à avoir une table de jointure pour ce qui doit être publié et où.Commencez par la même table posts, mais pas la colonne status.

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

Avoir un pour le blog d'une personne. Ensuite, créez une table de jointure reliant les publications à un article de blog.

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

Maintenant, quand quelque chose est « publié » c'est inséré dans blog_posts. Il n'y a pas de drapeau d'état. Si vous voulez voir un messages de blog de l'utilisateur ...

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

L'avantage est ici un poste peut apparaître à plusieurs endroits en ajoutant plus de tables de jointure ou plusieurs champs à la table blog_posts. Et il n'y a pas de champ status à ne pas oublier d'inclure dans chaque déclaration. Soit c'est dans la table de jointure ou ce n'est pas le cas.

blog_posts peut également présenter un champ publish_at.

Answer 2

visualiser en utilisant ceci:

sur "auteurs" Tableau:

essentiellement toutes les informations sur les auteurs

sur la table "Articles":

chaque article aura un auteur (généralement ... hmmmm mais il peut en avoir plus d'un possible mais cela fera l'affaire). donc la clé étrangère authors_id.

Pour la publication et le projet:

"publié" et "projet" sont dans le champ d'état. Dans ce cas, enum ('published', 'draft'). Sur votre isPublished? Je n'ai rien contre les conceptions db avec des valeurs booléennes (ie oui/non, vrai/faux) mais ce serait plus clair si vous l'avez enum. Probablement plus tard, vous ajouterez un autre statut et votre isPublished n'est plus pertinent. Un cas pourrait être: vous aurez besoin d'un statut plus tard sur qui dit: "publication programmée" ou dire "dépublier planifié" ou tout autre statut.

En ce qui concerne la table "blog":

Vous ne devez pas nécessairement que si vous avez un seul blog. Mais si vous avez plusieurs blogs, vous aurez besoin de cette table.

que pour le sql au-dessus:

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