Discussion :

[Aldéhir]

Bonjour,

Je travaille actuellement sur un site web. Les contenus y sont divers, mais peu "variés". J'ai donc au départ décidé de partir sur une table unique, avec cette structure :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE `contents` (
  `id_content` int(11) NOT NULL AUTO_INCREMENT,
  `name_content` text NOT NULL,
  `desc_content` text NOT NULL,
  `content_content` text NOT NULL,
  `pictype_content` varchar(15) NOT NULL,
  `type_content` varchar(50) NOT NULL,
  `theme_content` varchar(30) NOT NULL,
  `alaune_content` varchar(3) NOT NULL DEFAULT 'non',
  `favlvl_content` int(11) NOT NULL DEFAULT '0',
  `posttime_content` int(11) NOT NULL,
  `updatetime_content` int(11) NOT NULL DEFAULT '0',
  `answers_content` int(11) NOT NULL DEFAULT '0',
  `author_content` int(11) NOT NULL,
  PRIMARY KEY (`id_content`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 ;

Comme vous pouvez le constater, elle n'a pas bcp de colonnes. Enfin pas bcp comparé à d'autres tables gargantuesques qu'on peut parfois trouver.
Sa structure me permet de gérer des contenus de tout types : billets de blog, sujet de forum, tribunes libres, articles d'enseignement, actualités, etc, tous ces contenus partageant entre eux les mêmes caractéristiques.

Mes craintes se portent sur la taille finale de la table avec des milliers de contenus ajoutés. J'ai lu quelques articles sur la différence de perfs entre petites tables avec jointures et grandes tables. Mais le terme "grande" est à chaque fois utilisé pour désigner le nombre de colonnes, et non la "grosseur", le poids de a table, et évidemment, les petites tables sont à préférer les jointures ne consommant que peu de ressource.

Je bosse avec mysql. Je m'ouvre a vos avis parce que je voulais scinder cette table, mais je constate que si je donne à chaque type de contenu sa table, leurs attributs sont fatalement redondants, et à plus de 95%, chaque contenu ayant effectivement un theme, un auteur, une date de création de màj, etc.

A long terme, avec plusieurs centaines, voire milliers de contenus ajoutés, cette table unique risque t'elle de me poser des problèmes ? Fragmentation ? Erreurs ?

Merci d 'avance pour votre participation constructive

[Aldéhir]

Apres ce flot de réponses enrichissante j'ai décidé de laisser la table avec cette structure, à un détail pres. Les textes liés aux contenus, qui peuvent être très grands, ont été déplacés dans une table annexe.

De cette manière je peux maintenant créer plusieurs textes pour les lier au meme contenu, et les organiser sur le site sous forme de pages.

Merci de votre participation

[seabs]

Bonjour,

Pour t'indiquer, s'il te faut garder une table ou en créer plusieurs, il convient de vérifier la normalisation. Mais, à les lectures de tes quelques explications, il semble qu'il existe des redondances. Sauf raisons exceptionnelles, dès qu'il y a redondances, il faut mettre en place un schéma qui évite ces redondances, d'où la création de plusieurs tables.

Après pour t'apporter une aide efficace, il nous faut des explications plus complètes sur ton projet et sur le contenu qui va être stocké, au final, dans la base de données. Il serait bien d'établir les quelques règles de gestion qui assurer la gestion de la base, lesquelles permettront de comprendre et de modéliser.

Voilà certainement les quelques raisons qui expliquent pourquoi, tu n'as pas eu de réponse à ta demande

Bon courage

[CinePhil]

Comme l'a très bien dit seabs, on devine tout de suite qu'il y aura des redondances de données dans ta table. pictype, type et theme sont probablement à externaliser dans des tables de types de thèmes et de "pictype".

Si la colonne alaune_content n'est destinée à recevoir que oui ou non, comme le suggère sa valeur par défaut, autant utilise rle type BOOLEAN.

Les noms de colonnes posttime et updatetime suggèrent qu'il s'agit d'un horodatage. Pourquoi ne pas utiliser le type standard DATETIME ou TIMESTAMP ?

La colonne answers_content suggère qu'il s'agit ici de stocker le nombre de réponses. Si cette donnée est calculable par requête, il convient de ne pas la stocker dans une colonne qui risque un jour d'avoir une valeur fausse.

Un type VARCHAR ne serait-il pas suffisant pour les colonnes name_content et desc_content ?

[Aldéhir]

Boah c'était de l'humour. Je suis un incompris
Et merci Cinéphil pour le déplacement et le MP. Ton intervention est appréciée.

Alors. Donc pour plus de précisions :
- name stocke le nom du contenu qui est affiché comme titre
- desc la description
- content a été supprimé puisque déplacé dans une table annexe
- pictype stocke un truc comme jpg@jpg. Cette donnée est exploitée via un explode sur '@' pour récupérer en premier l'extension de l'image du contenu, et en second l'extension de la miniature de cette image.
- type_content et theme_content stockent une chaine : type peut etre "proposition", "essai", "problematique" et autres, et theme peut etre "economie" "politique" "education" et autres.
- alaune est un oui/non pour définir si le contenu apparait sur la Une du site dans le slider
- favlvl est un entier calculé par les partages, les like, les commentaires ajoutés, les remarques faites etc.
- posttime et updatetime sont donc des timestamp unix.
- answers enregistre le nombres de réponses au contenu
- author contient l'id de l'auteur

@seabs :
Concernant la redondance, par ex le thème du contenu (politique, economie, education, etc), La règle de gestion est donc :
Un contenu ne peut avoir qu'un seul thème.
Un thème peut etre utilisé pour plusieurs contenus.
Mais aucun outil ne permet d'ajouter des thèmes. Ce n'est d'ailleurs pas mon intention d'ne incorporer un. C'est pourquoi je me suis dit qu'il valait mieux avoir un champ theme_content. Me trompe-je ?
D'autant plus que cette règle est la même pour le type_content (proposition, essai, etc).

@cinephil
Concernant thème et pictype je pense avoir un peu répondu à ces interrogations. Qu'en pense tu maintenant que tu es en possession de ces infos ? Je doute qu'externaliser soit dans ce cas une optimisation =/
Pour le timestamp j'avoue que c'est fumeux ce champ Int, mais j'ai tellement de mal avec ce type DATETIME !
Pour le nombre de réponses dans answers, j'ai voulu procéder ainsi pour affichage rapide. J'imagine qu'un count sur 2000 commentaires et autant de remarques ralentit un tantinet la BDD non ?
J'ai modifié le nom et la desc en varchar en effet c'était bidon.

[CinePhil]

La première optimisation consiste à avoir un modèle de données normalisé au maximum.

Donc externalise les types et les thèmes, utilise un booléen au lieu d'un CHAR pour oui/non...
Bref, suis les conseils qu'on t'a déjà donné.

Et ta colonne qui contient des jpg@jpg à exploder en PHP, c'est pas top non plus !