BDD - Choix des tables

Bonjour,

Je viens vous demander un peu d'aide pour la conception de ma base de donnée. (désolé pour le titre non explicite)

Alors je souhaite créer un backend permettant l'ajout de news et d'articles. Que se soit pour les news ou articles, ils appartiennent à une catégorie (des catégories pour les news et d'autres pour les articles).

Quel est le meilleur moyen de faire cela :

• Faire deux tables catégorie (une pour news et autre article)
• Faire une table categorie qui contient toute les catégorie et une autre table liant l'id de la catégorie a un type (article ou news)
• Faire une seul table avec un champ en plus pour choisir si il s'agit d'une news ou article.

(le serveur sql ne bloque pas la création de vue)

Merci d'avance

Cordialement Mimos@

Salut Mimosa,

en fait, il faut que tu modélise ta base en identifiant les entités/propriétés.

Établis une liste des données que tu vas devoir manipuler, aussi détaillée que possible : par exemple, selon ce que tu as sommairement décrit, ça veut dire les données suivantes : article, titre, texte, catégorie, news. Partant de là, nous pouvons identifier quoi ? Que tu as dans tous les cas la même structure générale : un texe avec un titre mais une variante sur la catégorie. Rien ne l'indique, mais tu pourrais ajouter d'autres catégories dans l'avenir même si pour le moment c'est limité à «article» et «news».

On a donc deux entités : on va nommer la première «publication» et la seconde «catégorie».Elles ont toutes les deux des propriétés qui leur sont propres. la publication a un titre et un texte. La catégorie a un libellé. Ce qu'il est important de prendre en compte, c'est qu'une publication appartient à une (et une seule) catégorie mais qu'une catégorie peut correspondre à 0/n publications.

Ça, c'est notre modèle conceptuel de données : tu remarqueras que je n'ai jamais évoqué la notion d'identifiant : ça, ça va se passer au niveau du modèle physique de données. Mais pour le préparer, tu peux ajouter dans chaque entité une propriété supplémentaire : identifiant, ce qui va se traduire par pub_id (libellé de l'identifiant unique de la publication) et cat_id (identifiant unique de la catégorie) Das ton modèle pohysique, on va maintenant parler non plus d'entités et de propriétés mais de tables et de colonnes : une table publication avec les colonnes pub_id, pub_titre et pub_texte puis la table categorie avec cat_id et cat_libelle. Ajoutons la matérialisation de la relation avec dans la table publication la colonne cat_id. Voilà, nous avons nos deux tables qui te permettent de stocket tes textes en les affectant à la catégorie de ton choix. Si à l'avenir tu veux ajouter une catégorie, ton modèle ne changera pas, il suffira d'ajouter une ligne dans la table categorie et de relier éventuellement de nouvelles publications à cette nouvelle catégorie.

En résumé : ta seconde option était la plus appropriée :-)

Salut,

Merci de ta réponse. je posterai un schéma de ma BDD se soir chez moi pour avoir confirmation.

Bon voila je poste un schéma de ma base de donnée pour voir si je pars sur la bonne direction. Merci de m'indiquer si j'ai fait des erreurs ou si il y a moyen d'optimiser le tout.

A pardon le lien n'a pas marché, je le donne comme sa :

http://img403.imageshack.us/i/sql.png

http://img403.imageshack.us/img403/3618/sql.png

Salut Mimosa,

désolé, je t'avais laissé en plan.

Je viens de jeter un coup d'oeil à ton modèle, ça semble tenir la route à un détail près : la manière dont tu relies un commentaire à un membre ? il y a redondance entre le login de la table des commentaires et celui de la table membres.

Je te suggère par ailleurs une convention de nommage qui va te faciliter la vie. Ce que je fais systématiquement :

• Mes noms de tables sont toujours suffixées par un trigramme, par exemple pour les commentaires, ce sera commentaire_com;
• Toutes les colonnes sont préfixées par le tri_gramme de leur table d'appartenance, par exemple pour la clé primaire com_id et pour le texte du commentaire, ce sera com_texte.La table News devanant news_new, la clé étrangère dans commentaire_com aura le même nom que dans sa table d'origine : new_id : ça, c'est pratique pour faire de la jointure naturelle (JOIN sans la clause ON qui est définie directement par le SGBD si c'est supporté)

Salut,

Merci de ta réponse. Oui pour le nom des tables et colonne, sa deviens vite le bordel si on les nommes pas correctement.

Sinon pour la redondance, il n'y en a pas vraiment. Les membres ne sont pas liés aux commentaires, puisque l'on n'est pas obligé d'être membre pour poster un commentaire.

Je dirais qu'il y a quand même redondance. Il y a toujours quelqu'un pour posetr, que ce soit une news, un article ou un commentaire. La différence réside dans le fait que le posteur est membre ou non, et s'il est membre, identifié ou non.

D'accord, je ferais les modifications. Merci de votre aide.