Je suis en train de mettre en place un tableau qui pourrait avoir jusqu'à 70 colonnes. Je pense maintenant à le diviser car certaines données dans les colonnes ne seront pas nécessaires à chaque fois que le tableau est consulté. D'un autre côté, si je fais cela, je me retrouve à devoir utiliser des jointures.
À partir de quel moment, le cas échéant, considère-t-on qu'il y a trop de colonnes?
C'est considéré comme trop lorsque le nombre dépasse la limite maximale supportée par la base de données.
Le fait que vous n'ayez pas besoin que chaque colonne soit retournée à chaque requête est tout à fait normal; c'est pourquoi l'instruction SELECT vous permet de nommer explicitement les colonnes dont vous avez besoin.
En règle générale, la structure de votre table doit refléter votre modèle de domaine; si vous avez vraiment 70 (100, ou que sais-je) attributs qui appartiennent à la même entité, il n'y a aucune raison de les séparer en plusieurs tables.
@ChssPly76, il s'agit d'une base de données relationnelle et non pas d'un modèle objet. Il y a des tables, des lignes et des colonnes, travaillez dans cette contrainte si vous voulez des performances maximales, imitez vos objets pour plus de commodité au détriment des performances. Donc, chaque élément d'information sur une personne doit-il être stocké dans la même ligne ? Non, séparez-les et regroupez-les dans des tables différentes (en utilisant mon exemple de mon commentaire précédent) : "Personne", "Activités", "Dossiers médicaux". Stocker une SOMME pour des raisons de performances est un problème complètement différent que de garder toutes les données dans 70 colonnes pour éviter les jointures.
Doit "numberOfTeethPulled" faire partie de l'enregistrement Personne? Non, il ne devrait probablement pas être stocké du tout - vous obtiendrez ces informations à partir de "ToothExtractionRecord" si votre modèle de domaine nécessite un tel niveau de détail. Mais c'est VOTRE (et, oserais-je dire, plutôt artificiel) exemple - cela n'a rien à voir avec mon point: un grand nombre de colonnes dans une table ne signifie pas que la table est dénormalisée. Pensez aux contrats immobiliers / aux bons de commande / autres documents financiers, pour ne citer que quelques exemples. Peuvent-ils être divisés en plusieurs tables? Oui. Une raison de le faire? Pas vraiment.
+1, c'était hilarant. Si vous créez une autre table, et que ce n'est qu'une relation 1:1, vous devriez probablement simplement l'inclure dans la table principale. Cela ne va pas faire gagner d'espace, cela ne va pas améliorer considérablement les performances si vous ne demandez pas les données par rapport au fait qu'elles ne sont pas du tout dans la table. La seule raison légitime qui me vient à l'esprit actuellement, c'est s'il y a des informations sensibles telles que le SSN, les informations de carte de crédit, etc...
Il y a plusieurs avantages à diviser la table en plusieurs avec moins de colonnes, ce qui est aussi appelé Partitionnement Vertical. Voici quelques-uns :
Si vous avez des tables avec de nombreuses lignes, la modification des index peut prendre beaucoup de temps, car MySQL doit reconstruire tous les index de la table. Avoir les index répartis sur plusieurs tables pourrait accélérer le processus.
En fonction de vos requêtes et des types de colonnes, MySQL peut écrire des tables temporaires (utilisées dans des requêtes de sélection plus complexes) sur le disque. C'est mauvais, car les entrées/sorties sur disque peuvent être un gros goulot d'étranglement. Cela se produit si vous avez des données binaires (texte ou blob) dans la requête.
Une table plus large peut entraîner une performance de requête plus lente.
Ne vous lancez pas dans une optimisation prématurée, mais dans certains cas, vous pouvez obtenir des améliorations avec des tables plus étroites.
Je me posais la même question. Pourquoi MySQL reconstruit-il tous les index de la table ? La déclaration mentionnée ci-dessus est-elle correcte ?
C'est trop lorsque cela viole les règles de normalisation. Il est assez difficile d'avoir autant de colonnes si vous normalisez votre base de données. Concevez votre base de données pour modéliser le problème, non pas autour de règles artificielles ou d'idées d'optimisation spécifiques à une plateforme de base de données.
Appliquez les règles suivantes à la large table et vous aurez probablement beaucoup moins de colonnes dans une seule table.
Voici un lien pour vous aider.
Il est assez difficile d'obtenir autant de colonnes si vous normalisez votre base de données. Pas aussi difficile que cela ne semble.
Certainement pas si difficile. Les gens ne semblent pas vraiment comprendre les formes normales ici. Vous pouvez avoir 10000 colonnes et être ENCORE normalisé (même jusqu'à la plus haute forme normale).
Je trouve cela très difficile à croire. Bien sûr, il y a des cas extrêmes, mais en général, il semble très difficile de penser à un objet avec 1000 attributs distincts qui ne peuvent pas être regroupés.
Ce n'est pas un problème sauf si toutes les attributs appartiennent à la même entité et ne dépendent pas les uns des autres. Pour faciliter la vie, vous pouvez avoir une colonne de texte avec un tableau JSON stocké dedans. Évidemment, si vous n'avez pas de problème à obtenir tous les attributs à chaque fois. Cependant, cela serait totalement contre-productif de les stocker dans un SGBDR et compliquerait considérablement chaque transaction de base de données. Par conséquent, il ne s'agit pas d'une approche recommandée à suivre dans toute la base de données.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
8 votes
Nous n'avons pas toujours besoin d'utiliser SELECT * tout le temps. Nous avons toujours la possibilité de sélectionner uniquement les colonnes dont nous avons besoin pour une situation donnée.
3 votes
70 colonnes ?! Combien d'entre elles ne peuvent pas être nulles?
1 votes
La grande question est ... normalisez-vous vos tables? 70 est une quantité inhabituelle à moins que vous ne dénormalisiez délibérément pour des performances (très peu de choses ont 70 attributs uniques). Si vous dénormalisez pour des raisons de performances, alors je serais d'accord avec ChssPly76 pour dire que vous pouvez utiliser tout ce que la base de données vous permettra de faire passer.
3 votes
@KM. Est-ce censé être une blague? Je suis nouveau sur MySQL et je ne comprends pas, vouliez-vous dire que JOIN est une bonne chose ou quelque chose à essayer d'éviter?
0 votes
@Helga Iliashenko, l'OP est stressé à l'idée de diviser sa table parce que
"si je fais cela, je suis obligé d'utiliser des jointures.". Oui, mon commentaire est une blague car les jointures sont essentielles en SQL. Permettez-moi de le dire ainsi : les JOINTURES sont à SQL ce que tourner à gauche/droite est à la conduite d'une voiture. Les jointures sont la base de SQL, si vous ne pouvez pas ou ne voulez pas les faire, vous feriez mieux de trouver une autre carrière.2 votes
Autant les joints sont une partie essentielle de SQL, les joindre juste pour le faire risque probablement de dégrader les performances et la maintenabilité de votre application.