Est-ce utile de stocker une même information dans plusieurs tables?

[ChriGoLioNaDor]

Bonjour,

Lorsque j'ai appris à créer des tables SQL, mes professeurs m'ont toujours dit qu'une des règles à respecter était de ne jamais stocker une même donnée dans plusieurs tables, pour des raisons de taille de la table et surtout de cohérence (en cas de modification de la dite donnée, par exemple)...

Cependant, alors que j'étudiais les bases de données de plusieurs forum (phpbb et fluxbb pour ne citer qu'eux), j'ai remarqué que certaines données étaient répétées de nombreuses fois. Entre autre, le nom d'utilisateur, mais aussi le titre du dernier message et sa date. En effet, pour ne prendre que le nom d'utilisateur, il apparait dans les tables "users", "posts", "topics", "bans"...

D'où ma question. Est-ce là une pratique permettant de ménager la BDD en lui évitant des jointure à chaque fois que quelqu'un consulte la page pour retrouver le pseudo du posteur? Ou simplement un "défaut" de conception qu'ont ces forums ?

Merci d'avance pour vos réponses!

[CinePhil]

Envoyé par ChriGoLioNaDor

D'où ma question. Est-ce là une pratique permettant de ménager la BDD en lui évitant des jointure à chaque fois que quelqu'un consulte la page pour retrouver le pseudo du posteur? Ou simplement un "défaut" de conception qu'ont ces forums ?

Je dirais les deux.
Un forum peut effectivement comprendre un très grand nombre d'entrées, Developpez.net est là pour le prouver.

Le principe général est qu'il faut commencer par normaliser au maximum sa conception et ensuite seulement s'autoriser des dénormalisations en les testant l'une après l'autre pour voir si elles sont utiles en terme de performance.

Dans les cas que tu cites, je crains qu'on ait à faire à des développeurs qui n'ont peut-être pas une grande connaissance des bases de données plutôt qu'à de vrais concepteurs qui ont effectué la démarche citée plus haut. Mais je suis peut-être mauvaise langue...

[Alain Defrance]

Bonjour,

la raison pour laquelle les professeurs interdisent la redondance d'information est qu'ils enseignent le modèle merise qui garanti une économie de place maximal et évite les incohérences dans la base de donnée.

Cette méthode est reconnu comme performante mais est aussi très discuté concernant, par exemple, l'optimisation.

Il peut arriver de dégrader ce modèle pour soulager le SGBD. Bien évidement il faut peser le pour et le contre, et éviter les redondance lorsque ça n'apporte pas grand chose

[rberthou]

Ne pas oublier que le modèle relationnel (contrairement aux bases de données hiérarchique) IMPLIQUE une redondance des données pour permettre les relations entre ces tables (les zones clefs sont naturellement redondantes).

[CinePhil]

La redondance, dans une clé étrangère, d'une clé numérique auto-incrémentée et la redondance d'un nom par exemple, ce n'est quand même pas la même chose !

Un exemple :
TablePrincipale(id, nom)
TableLiee(id, nom_TablePrincipale, ...)

Zut ! J'ai mal écrit le nom de M. Schtroupmpf ! Je corrige de suite.
Manque de bol, il figure aussi dans la table liée avec la mauvaise orthographe et j'oublie de le changer. Oui je sais, ON UPDATE CASCADE existe mais il y a fort à parier que celui qui a choisi de répéter le nom n'a probablement pas utilisé les contraintes de clés étrangères.

Je suis caustique moi aujourd'hui !

[Alain Defrance]

Sans compter que l'update cascade s'applique à des foreign key, c'est à dire généralement à des identifiants, alors à moins de lier les données par des titres (), l'update cascade ne servira a rien.
De plus puisque les foreign key concernent généralement que des identifiants, et qu'un identifiant ne dois JAMAIS changer, l'update cascade est rarement utile, a un tel point que Oracle ne l'implémente même pas.

[CinePhil]

Envoyé par kazou

l'update cascade est rarement utile

Justement je me demandais à quoi ça servait !

[ChriGoLioNaDor]

Merci pour vos réponse, ça me rassure pas mal

Pour tout dire, je pensais appliquer une solution hybride. En effet, je trouve ça assez choquant d'aller mettre le nom du posteur partout. Si un jour il doit être changé... Et s'il a un identifiant, c'est dommage de ne pas l'utiliser. Par contre, je comprends aussi qu'une information concernant le dernier post soit placé dans la table "topics", afin de ne pas avoir à parcourir l'ensemble de la table "posts" à chaque affichage, pour le trouver ^^

Je pensais donc faire quelque chose comme ça :

Code :

1
2
3
4
Users(user_id, user_name, user_pass, user_email)
Topics(topic_id, topic_subject, num_replies, last_post_id)
Posts(post_id, user_id, topic_id, post_datetime, post_message)
Forum(forum_id, forum_name, num_topics, last_subject_id)

Je n'ai donc pas à trouver à chaque vue de la page le dernier sujet/message, ni à calculer le nombre de réponse/sujet, mais d'un autre coté je ne stock pas 36 fois le nom du dernier sujet par exemple...

Cela vous semble-t'il un bon compromis?