Bonjour,

J'avais l'impression en première lecture que ma question rejoignait le post gestion des tables ... mais les réponses m'ont fait douter, je reformule donc une question pour mon propre cas.

[modérateurs, vous pouvez fusionner avec l'autre si vous voulez, mais je ne voulais pas couper le débat..]

J'aurais besoin de multiplier les colonnes d'une de mes tables, avec pour chaque membre une ligne unique. Vaut-il mieux avoir deux tables de 20 colonnes avec une ligne seulement pour chaque membre, ou une seule table de 40 colonnes ? Y-a t-il un problème à multiplier le nombre de colonnes, en termes de performance ou de relecture ?

Voilà merci de vos réponses

Salut,

en effet, je pense qu'il s'agit du même problème que le sujet auquel tu fais référence...

Ensuite, ça dépend un peu des cas... Si t'as un espace disque suffisant, je pense qu'il est peut être plus intéressant d'avoir une table plus grosse avec des champs NULL. Les requêtes seront plus simples (sans jointure) et donc moins couteuses en ressource (avec des index qui vont biens...)

Aucun problème avec une table de 40 colonnes (par ex la plupart des logiciels de gestion fonctionnent sur des schémas de tables avec de nombreuses colonnes), si ce n'est la limite physique pour un enregistrement qui va te contraindre à des formats de données de faible taille, selon la bdd que tu utilises et la nature des traitements.

Ceci peut poser problème pour les développements futurs.

Selon ma modeste expérence tu peux gérer un projet d'une centaine de tables de 5 à 40 colonnes sans dénormaliser, à condition d'avoir une base de données supportant les procédures stockées pour les requêtes complexes.

La commande ON DELETE CASCADE est utile pour les suppressions sur des tables normalisées.

Les triggers sont utiles si tu commences à dénormaliser.

Merci pour vos réponses !

Je vais donc gonfler cette table... Même si je pourrais certainement réunir tous les chiffres en varchar 1-0-1-1-1-0 par exemple, je pense faire plusieurs colonnes en smallint (jusqu'à 3 caractères par colonne), ça semble aller ? Il n'y a pas de champs nul, ce ne sont que des compteurs en pourcentage là, donc pas de problèmes de NULL, à priori.

J'ai aucune formation en bases de données, c'est vrai que j'en garde une utilisation très basique, sans aucune idée de l'optimisation à apporter à un projet. On va dire que je me débrouille comme je peux

Salut,

je suis convaincu qu'il est (beaucoup) plus rapide de rajouter plusieurs champs SMALLINT plutot que de faire un seul champs VARCHAR qui nécessitera ensuite de nombreuses opérations (en php) pour finalement obtenir la valeur cherchée.

La valeur NULL peut de temps en temps se révéler très intéressante pour les pourcentages... Par exemple, pour un système de note où il n'y a eu encore aucun vote... NULL me sembe plus approprié que 0%. Mais il est vrai que l'on peut se dispenser de cela quand il faut au moins un vote pour apparaitre dans la table considérée...

A+