web-dev-qa-db-fra.com

Structurer une base de données pour un blog

J'ai construit une base de données pour un blog. Je suis encore étudiant, donc mes connaissances sont limitées dans ce domaine. Je poste cette question pour obtenir une brève description de ce que je fais mal, pourquoi et comment je peux y remédier. Je ne suis pas un développeur back-end, donc si vous avez mal compris quelque chose de ce post, je vais l'expliquer plus loin.

Il s'agit d'un simple projet de blog. Les procédures suivantes sont disponibles pour l'administrateur et l'utilisateur.

[~ # ~] admin [~ # ~]

  • Inscrivez-vous en tant qu'auteur sur le blog
  • Publier
  • Écrire et rédiger un article

[~ # ~] utilisateur [~ # ~]

  • Afficher un article
  • Comme le poste
  • Poste un commentaire
  • J'aime le commentaire

Voici les tableaux que j'utilise pour les procédures ci-dessus:

  • auteurs (contient les auteurs enregistrés du blog)
  • articles (contient toutes les informations nécessaires pour un article)
  • commentaires (contient les données nécessaires pour un commentaire)
  • likes_counter (contient les likes uniques qu'un utilisateur fait sur un post ou un commentaire)

Relation entre les auteurs et la table des publications

J'utilise une relation un à plusieurs pour connecter les auteurs et les messages tableaux. Chaque auteur peut écrire plusieurs articles et chaque article a besoin d'un seul auteur.

Le diagramme EER est donné ci-dessous:

authors and posts database diagram for a blog

Et voici à la fois les auteurs et les messages schémas de table:

CREATE TABLE IF NOT EXISTS `authors` (
  `author_ID` bigint(10) unsigned NOT NULL AUTO_INCREMENT,
  `author_name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `author_avatar` text COLLATE utf8_bin NOT NULL,
  `author_description` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`author_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `posts` (
  `post_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `post_date` datetime NOT NULL,
  `post_content` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `post_status` varchar(20) COLLATE utf8_bin NOT NULL DEFAULT 'draft',
  `post_type` varchar(10) COLLATE utf8_bin NOT NULL,
  `post_like_count` int(10) unsigned NOT NULL DEFAULT '0',
  `post_comment_count` int(11) unsigned NOT NULL DEFAULT '0',
  `post_has_article` tinyint(4) NOT NULL DEFAULT '0',
  `article_title` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `article_content` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`post_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;

Q1

Est-ce comment créer la relation?

Tableau des commentaires

  • Chaque message peut contenir des commentaires
  • Les utilisateurs ne peuvent pas répondre aux commentaires
  • Chaque commentaire peut être favorisé

Ci-dessous le schéma:

Comments database diagram for a blog

Et le schéma de table:

CREATE TABLE IF NOT EXISTS `comments` (
  `comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `comment_post_ID` bigint(20) unsigned NOT NULL,
  `comment_count` bigint(20) unsigned NOT NULL,
  `comment_author` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `comment_author_IP` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `comment_date` datetime NOT NULL,
  `comment_content` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `comment_approved` tinyint(4) NOT NULL DEFAULT '0',
  `comment_like_count` int(10) unsigned NOT NULL,
  `comment_author_email` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`comment_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;

Q2

Ma principale préoccupation est de savoir comment savoir quel message contient quel commentaire. J'ai créé une colonne comment_count qui contient l'identifiant du message actuel.

Exemple:

Disons que nous avons trois articles avec des identifiants 300, 301, 302 et quatre commentaires. Ensuite, chaque ligne prendra la forme suivante:

comment_ID  -  comment_post_ID - comment_count
1              300               1
2              301               1
3              301               2
4              301               3

L'article dont l'ID est 302 n'a pas de commentaire, donc aucune ligne n'est enregistrée. Je pense que c'est une sorte de relation plusieurs à plusieurs , mais pas exactement. Le bon formulaire est-il à utiliser?

Table Likes_Counter

Ce fut de loin la décision la plus difficile que j'ai prise.

  • Chaque article peut être favorisé
  • Chaque commentaire peut être favorisé
  • L'utilisateur n'aura besoin d'aucun compte pour effectuer cette action.
  • Il ne peut favoriser un élément (publication ou commentaire unique) qu'une seule fois. Pas de favoris en double autorisés

Je ne sais vraiment pas si tout cela devrait être contenu dans un seul tableau.

La pensée était simple. Nous obtenons l'id de fav (commentaire ou publication) et nous l'affectons à la même colonne nommée. Nous obtenons également l'adresse IP de l'utilisateur. Donc, au final, nous savons si un utilisateur a déjà favorisé un article ou non. Mais je ne sais pas si ma mise en œuvre est bonne (et par là je suis maintenable).

Diagramme:

set up a likes diagram for a blog

Schéma:

CREATE TABLE IF NOT EXISTS `likes_counter` (
  `like_ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `like_type` varchar(10) COLLATE utf8_bin NOT NULL,
  `like_content_ID` bigint(20) NOT NULL,
  `like_IP` varchar(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`like_ID`),
  KEY `like_ID` (`like_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;

Je sais que ce fut un long post mais j'apprécierai déjà vos réponses.

mysqldatabase-designrelations
3
user101258

Conseils:

  • Si un avatar est une image, utilisez BLOB, pas TEXT.
  • Ne préfixez pas chaque nom de colonne avec le nom de la table; il encombre inutilement.
  • Il est peu probable que vous ayez besoin de BIGINT; utilisez plutôt INT UNSIGNED (max ou 4 milliards).
  • Un PRIMARY KEY Est un UNIQUE key Est un KEY. Ne ré-indexez donc pas le PK.
  • Pensez à utiliser ENUM pour des choses comme status et type.
  • Un Post a à la fois un article et un content? Quoi de neuf?
  • Les adresses IP, si elles sont conservées sous forme de chaînes, peuvent être VARCHAR(39) CHARACTER SET ascii.
3
Rick James