Discussion :

[S-Kayp]

J'aimerai savoir quel est le nombre de colonnes conseillé dans une table, pour éviter, par exemple, que ca ralentisse les requettes.
Apparemment, on peut aller jusqu'à 2000.

Moi, j'aurais une table d'environ 60 colonnes : est-ce que ca reste correct ?

[rberthou]

C'est bien sur parfaitement jouable 60 col.

Je pense surtout qu'avant d'être un problème de perf un nombre de colonnes trop élevés est un problème de modélisation .

[S-Kayp]

C'est vrai que, quand on a des tables avec beaucoup de colonnes, on peut être perdu !

[SQLpro]

Le moins possible. Cela découle de l'élaboration des modèles de données en respectant les formes normales...
Si vous respectez l'ultime forme normale (rarement enseignée) n°6, alors vous ne devriez avoir que des tables constituée d'une clef (primaire) et d'une seule et unique colonne en sus des colonnes constituant la clef primaire.

Sachez que plus vous aurez de colonnes dans une table plus les performances chuterons de manière quadratique au nombre des colonnes.

Dans mes audits, je traque les tables ayant plus de 20 colonnes. Si cela n'est pas totalement justifié (respect des formes normales de 1 à 3 au moins) alors je sévit.

Alors quand j'entends parler de table à 60 colonnes, voire 2000 je pense que vous devriez faire du COBOL et laisser tomber les bases de données relationnelles...

A +

[S-Kayp]

Pour ce qui est de 2000, c'est dans la fac de mysql ; on peut au maximum avoir 2000 colonnes dans une même table !

Moi ce que je cherche, c'est savoir quel est le nombre de colonnes qui est conseillé (et donc à ne pas dépasserà pour une même table.

Quand je dis que je pourrais avoir une table avec 60 colonnes, c'est parce que sa représente un "membre" et que ca contient des détails sur les membres : infos diverses, description, caratères, goûts etc...
Par contre, les valeurs des colonnes seront souvent des chiffres. En effet, pour gagner de la place, je compte numéroter chaque réponse d'une liste par un numéro, et enregistrer ce numéro au lieu de la réponse choisie. Mais je pense que la plus part des sites internet doivent faire ca.
Par exemple, si pour la colonnes "couleurs de cheveux", j'enregistre "1" à la place de "blond", si vous avez 2000 membres blonds, entre 2000 fois "1" et 2000 fois "blond", ca fait une grosse différence d'octets.

[rberthou]

Alors quand j'entends parler de table à 60 colonnes, voire 2000 je pense que vous devriez faire du COBOL et laisser tomber les bases de données relationnelles...

Désolé mais même en cobol cela est très fortement déconseillé (mais cela apparait encore dans de vieux programmes utilisant des fichiers).

[S-Kayp]

OK, vous dites que 60 colonnes c'est trop - colonnes >> on pourrait aussi dire champs - alors combien me conseillez-vous ?

Je pourrai partager ma table "membre" en plusieurs : infos personnels, description, caractère etc...
C'est ce que j'avais prévu au départ, mais je m'étais dit qu'en faire une seule serait pas mal, ce qui évite trop de jointure dans une requette.

C'est donc pour ca que je demande combien il ne faut pas dépasser. Et si on a trop de colonnes, les requettes sont plus longue en temps d'exécution ?

[Alain Defrance]

Disons qu'il faut autant que possible éclater les données.
Cependant je pense qu'il faut trouver un juste milieu.
En effet, plus les tables sont nombreuses et les données explosées, et plus il faudra faire de jointure. Et les jointures sont très couteuses ressource pour le SGBD.
Il faut donc suffisement soigner le modèle pour éviter de surcharger le SGBD.
Le problème c'est qu'on enseigne souvent merise, et le SQL, sans expliquer ce qui se passe derrière, on ne peut donc pas demander a des novices d'utiliser intelligemment un SGBD, c'est pour que les formes normal garantissent une utilisation correcte de la base de données.
Comme le dit SQLpro, la forme ultime de merise donne un nombre très très important d'entité, à savoir une par propriété.
Cette forme normal est rarement enseigné car rarement utilisé. Souvent, le modèle merisien est dégradé et donc n'obéit pas aux formes normales.
Beaucoup de modélisateur ne respectent eux même pas forcement ce modèle car il est souvent mal utilisé par les entreprises.

20 champs sur une table ça se discute, et il faudrait voir sil il n'est pas plus correcte de l'alléger. En ce qui concerne la rapidité du SGBD, c'est pas la différence entre 10 et 20 champs qu'on verra une différence significative.
Les 20 champs sont plus embêtant au niveau conceptuel et il y a certainement des améliorations a faire.

[S-Kayp]

Oulà, "merise" car remonte à loin, 7 / 8 ans, et je ne souviens plus trop de ca LOL

Si les jointures consomment beaucoup de ressources, autant que je limite le nombre de tables se rapportant à la même chose.
Etant donné qu'il s'agit de "membres", si il y a beaucoup de personnes qui font une recherche de membres avec critères, il faut que les requettes ne rame pas.

[Alain Defrance]

Attention, les jointures sont certes une opération lourde pour le SGBD, mais il y est quand même habitué, c'est une belle bête le SGBD.
Pour des membres en effet ça ne semble pas tellement gênant d'avoir 20 champs, mais avec un modèle on pourrait certainement t'aider a améliorer cela.

Ce qui me chagrine en revanche, c'est que tu exploite une base de donnée sans modèle préalable, ça c'est grave :p

[S-Kayp]

non pas du tout, je n'ai pas encore de base de données, je suis en train d'en faire le modèle : pour savoir quels champs j'aurais et combien de tables, entre-autres.

[Alain Defrance]

Ah c'est différent alors, toutes mes excuses

[S-Kayp]

ce n'est pas grave !

[S-Kayp]

J'ai pu éclater ma table membre en 4 tables ayant chacune entre 10 et 20 champs - je (re)précise que ce n'est qu'un plan de ma future base de données.

Et là je pense que ca devrait être bon.

[Alain Defrance]

Pourrait-tu nous montrer le MCD (si tu veux des avis) ça serait plus parlant

[S-Kayp]

Voici le MCD pour par la partie "membres".
J'ai mis le nom de ce que réprésente chaque champs et non le nom qu'auront ces champs dans ma base de données.