Meci pour vos reponses, je vais essaye d'etre un poil plus precis
Oui serialiser les donnees dans un champs n'est meme pas envisageable, des recherches doivent pouvoir prendre en compte tous les champs.

En fait, chaque enregistrement appartient a une famille definie par une 20aine de champs.
En gros l'enregistrement 1, appartenant a la famille A, utilisera les 20 champs communs a tous les records plus une 20aine d'autres pour sa famille.
Le record 2 de la famille B, utilisera aussi les 20 memes champs communs mais aussi 20 autres specifiques a la famille B, donc different de ceux de la famille A.
Pour resumer, il y aura 6 familles avec chacune 20 champs + 20 champs commun. Donc pour un enregistrement on utilisera 40 colonnes sur 140.

Donc soit je fais une table avec les 20 champs communs et 6 autres table, une pour chaque famille, ce qui me semble esthetique et convenir a la situation ; Soit je fait une seule et unique table avec 140 colonnes.

La deuxieme solution est un peu plus simple a gerer, plus performante mais beaucoup moins maintenable. Si demain il faut ajouter 3 nouvelles familles, ca fait tout de suite une table avec 200 colonnes.
Je n'ai pas d'objection a cette idee, mais ce n'est pas tres jolie et ca oblige a creer des vues pour parcourir la table (afficher 200 col avec le client mysql en ligne de commande n'est meme pas envisagable, et je suis trop faineant pour specifier a chaque fois les champs que je veux :p)

Bref en gros je voudrais savoir si vous voyez d'autres arguments qui pourra appuyer mon souhait d'utiliser plusieurs tables.
N'y a t'il vraiment aucune difference entre travailler sur une table avec 30 col et sur une table avec 200 col niveau performance ?
Si vous avez des retour d'experience ca peut m'interesser

Merci

Hugues

merci Zeus

ne sois pas désolé, c'était juste une interrogation qui m'était venue à l'esprit
accessoirement j'avais bien spécifié l'idée de regrouper les champs ne servant à aucune recherche mais, à y repenser apres coup, il est vrai que cela implique aussi l'impossibilité de raffiner les données récupérées.

bonne journée !

Désolé Jules, mais c'est une très mauvaise idée ...

Stocker plusieurs valeurs dans un champ nous prive de toutes les fonctionnalités du SGBD sur ces champs : tri, recherche, groupement ...

Il vaut mieux avoir des champs vide, surtout que si le type est bien foutu, il ne prendra aucune place physique, que de mutualiser les champs

hello,

loin de moi l'idée de détourner le post, mais peut etre que ma question peut apporter une solution ou l'inspiration à Golin

donc cette question m'inspire une autre question (peut-etre bete ?) :

prenons le cas d'une table à 200 champs. Il est fort probable que seuls 5 ou 6 champs seront utiles pour des recherches, le reste n'étant que de la donnée à récuperer.

peut-ce etre intéressant dans ce cas de stocker tout le reste (en séparant par des délimiteurs ou en sérialisant ou autre) dans un seul gros champ que de multiplier les champs ?

l'idée étant de simplifier la structure de la table, meme si cela donne un peu plus de travail à php ?

bonne journée !

Oh Galinette,
tu crois pas que ce serait plus facile de te répondre
si on avait la structure de tes tables ?

En fait, il n'y a pas de règle absolue en la matière.
Tout dépend des structures de tes tables (identiques ou non)
et de leurs contenus (valeurs nulles, "matrice creuse", etc.)

Bonjour (et desole pour le titre pourri),

Je dois refaire la structure d'une base de donnees pour un site a fort trafic dont la priorite est d'optimiser les performances.
Le but est de gerer des records qui ont tous des champs communs et apres, selon la famille du record, des champs specialises.

Ma premiere idee fut donc de creer une table contenant tous les elements communs a chaque row et ensuite creer une table pour chacune des 6 familles avec les champs adequates.
Les pages de parcours ne necessitent ainsi que des select sur la table commune. La page qui affiche le contenu d'un record doit : soit faire un select sur la table commune et un autre sur la table ou sont les champs specialises, soit faire un select sur les 2 tables avec une jointure.
Et les recherches imposent une lourde requete avec une jointure.

L'architecte dit que, pour optimiser les performances, il vaut ne faire qu'une unique table (meme avec 200 colonnes) plutot que de faire 2 tables separees avec deux petits select.

Je trouve ca pas tres esthetique, ca impose l'utilisation de vues pour pouvoir browser la table... bref je vais faire des benchs (bien que le gain de performance est evident) et j'aimerai l'avis de gens car je sais qu'une enorme table c'est moins facilement maintenable.

Merci.

Hugues.