Version imprimable
bonjour,
j'ai lu sur le FAQ :
j'ai une table qui a 30 colonnes, j'ai créé une autre table ayant 10 colonnes alors que je peux mettre ces colonne dans la première tableCitation:
Une table peut contenir jusqu'à 4096 colonnes. Évidemment, une table avec un grand nombre de colonnes aura un impact sur les performances.
je sais pas comment le nombre de colonnes a un impact sur la performance de moment que je fais une requête SELECT que sur les colonnes désirés
merci d'avance
Lisez l'article que j'ai écrit à ce sujet : https://blog.developpez.com/sqlpro/p...mances_petites
A +
merci beaucoup,
l'article m'a vraiment aidé à comprendre certaines nouvelles chose
je vais opter à de petites tables normalisées pour les meilleures performances
Bonjour
Quand vous parlez de table obèses vous parlez uniquement en nombre de colonnes (champs) ou en poids des contenus.
1°) Si j'ai 200 champs avec peu d'info dans les champs, suis-je une table obèse ?
2°) Si j'ai 10 champs mais que j'ai beaucoup de contenu texte dans un de mes champs, suis-je aussi une tableau obèse ???
Lisez l'article de SQLPro !
200 colonnes (et pas champs) dans une table, c'est énorme !
C'est souvent le signe d'une mauvaise modélisation des données si la table dépasse quelques dizaines de colonnes.
Par contre, une table avec peu de colonnes mais des colonnes contenant du texte, ça peut être nécessaire. C'est la cas des tables des CMS ou des forums, par exemple, et, bien que la plupart des modèles de données de ces logiciels ne soient pas top, ça ne pose pas de problèmes. Il est normal de stocker les textes de nos parfois longs messages de forums dans la base de données.
L'essentiel, c'est de bien modéliser les données.
Et donc la question qui tue lol... tout cela pour en arriver la ;)
Pour faire mieux que pas top... ça serait quoi l'idéeCitation:
C'est la cas des tables des CMS ou des forums, par exemple, et, bien que la plupart des modèles de données de ces logiciels ne soient pas top, ça ne pose pas de problèmes.
Car quand on réalise sa base POST, CATEGORY.... la 1ere idée c'est de se calquer sur ce qu'il se fait au niveau des CMS...
Mais la 2ème idée c'est de se dire puisque je fais ma propre base, n'y aurait-il pas des piste à améliorer (j'ai moins de fonction, j'ai pas besoin d'être compatible ou rétrocompatible...)
Quand vous dites que les modèles des CMS ne sont pas top... il faudrait faire quoi pour avoir une Bdd POST et CATEGORY au top ;)
Un regard critique sur la bd WP serait intéressant car au moins tout le monde parle de la même chose (n'ayant pas encore finalisé mon projet et en plus tout le monde s'en fiche de mon projet) alors qu'une étude de cas sur une base que tout le monde connait ça c'est plus constructif
Salut à tous.
Non, vous n'avez pas compris le message de SQLPRO. La règle c'est la performance !Citation:
Envoyé par CinePhil
Et pour arriver à une bonne performance, vous devez au préalable modéliser votre base de données.
D'ailleurs SQLPRO le dit :
Citation:
Envoyé par SQLPRO
Et parfois, pour améliorer les perfomances, il est nécessaire de dégrader la base de données. Mais bon, ça c'est un autre problème.Citation:
Envoyé par SQLPRO
Donc, non, c'est pas l'essentiel, mais juste une condition nécessaire et non suffisante !
C'est ce que scamphp a fait, d'où sa question sur ce que l'on nomme une table obèse.Citation:
Envoyé par CinePhil
Je réponds à sa question.
Dans cette article, nous nous trouvons dans la modélisation et le problème soulevé est bien le nombre de colonnes d'une table.
Il faut externaliser les colonnes en fonction de leur fréquence d'utilisation, mais aussi de leur pertinence.
L'exemple classique des adresses, des numéros de téléphones, qui enfreingnent les formes normales. Pourquoi ?
Par ce qu'une personne peut avoir de 0 à N numéros de téléphones. Même remarque pour les adresses.
Pour la volumétrie, il s'agit plutôt d'une question technique et la solution est d'utiliser des partitions.
Il n'y a pas de solutions générales, mais que des cas particuliers.Citation:
Envoyé par Scamphp
L'exemple est d'externaliser les messages dans une table dédiée à cela.
NON !Citation:
Envoyé par Scamphp
C'est avant tout un problème de modélisation et de performance.Citation:
Envoyé par Scamphp
On ne peut pas répondre simplement à une question d'ordre générale.
Si je prends le cas donnée par SQLPRO sur le numéro de la sécurité sociale, il faut au préalable se poser quelques questions.
Du genre, les recherches que vous désirez faire sur cette colonne.
Si vous ne faites jamais rien, alors une seule colonne de type char peut suffire.
Si vous avez besoin de faire des recherches plus fine, il est nécessaire d'éclater le numéro de sécurité sociale en plusieurs petites colonnes.
C'est le besoin que vous avez, qui va conditionner la représentation de vos données dans votre base.
Donc non, il n'y a pas de solutions toutes faites
Ne confondez pas le stockage des données, son exploitation et sa présentation.
@+
Par exemple, concernant le modèle de données de Wordpress...
Dans la table wp_users (qui devrait être nommée au singulier) :
- colonne user_pass en VARCHAR(255)... je ne voudrais pas être l'utilisateur qui ait un mot de passe à 255 caractères ! :mouarf:
- colonne ID en UNSIGNED BIGINT soit un potentiel de 2^64 utilisateurs !!! Que celui qui fait un site avec Wordpress à plus de 4 milliards d'utilisateurs (taille du UNSIGNED INT) se fasse connaître ! :mrgreen: En attendant, c'est 2 fois plus de place (8 octets au lieu de 4 par ligne) pour stocker ça dans cette table et en tant que clé étrangère dans beaucoup d'autres.
Et une table wp_usermeta (pourquoi pas !) mais qui stocke des propriétés qui peuvent s'appliquer à tous les users ou presque. Donc des meta_key en VARCHAR(255) qui se répètent pour un très grand nombre, voire la totalité des utilisateurs.
Dans la table wp_posts (qui devrait être nommée au singulier) :
- une colonne post_status en VARCHAR(20) alors que la liste des status possibles est limitée et devrait faire l'objet d'une table de référence séparée ;
- idem pour la colonne post_type...
Et des dénormalisations de la sorte, j'en ai trouvé dans les BDD de Wordpress, Joomla, Drupal, Joomla, GLPI, PMB, Moodle...
Avec en plus une programmation objet utilisant un ORM qui génère une masse de requêtes beaucoup plus grande que le nécessaire, ça finit par donner des sites lents qui nécessitent des ressources machines plus importantes.
Alors qu'avec un bon modèle de données, n'importe quelle requête, même un tant soit peu complexe, s'exécutera en une fraction de seconde, même avec des millions de lignes et une machine qui n'est pas une bête de course. À titre d'exemple, encore, j'ai développé, il y a 10 ans, une base de données à partir de fichiers plats extraits de deux années du ficher national d'identification des bovins. 63 millions de bovins, des milliers d'éleveurs, des millions de mouvements de bovins (vente, exportation, importation, abattage...) et toutes mes requêtes s'exécutaient au plus en quelques secondes sur un petit serveur de l'époque qui ne contenait pas que cette base données.
Salut CinePhil.
Je vous signale que plus le mot de passe est long et plus il est difficile de le cracker. Donc non, cela ne me choque pas.Citation:
Envoyé par CinePhil
C'est grand, je le reconnais. Mais rien n'indique que la colonne en question soit auto incrémenté. Si ce type existe, ce n'est pas sans raison.Citation:
Envoyé par CinePhil
Vous portez un jugement de valeur sans comprendre la problématique de l'utilisateur qui aura besoin de ce type.Citation:
Envoyé par CinePhil
Oui et alors ? Ce n'est pas parce que vous pouvez mettre 4 milliards d'utilisateurs que cela sera le cas.Citation:
Envoyé par CinePhil
On arrive sur des vieux forums, à obtenir plus de 90% d'utilisateurs inactifs.
Là, je suis d'accord avec vous. C'est pas du tout performant comme approche !!!Citation:
Envoyé par CinePhil
Je suis encore d'accord avec vous.Citation:
Envoyé par CinePhil
Ce ne sont pas des dénormalisations, c'est du grand n'importe quoi. Nuance.Citation:
Envoyé par CinePhil
La dénormalisation a pour but d'améliorer les performances et non le contraire.
N'exagérez pas ! Un modèle de données n'est pas la panacée aux problèmes de performances. Elles y contribuent grandement.Citation:
Envoyé par CinePhil
Et que faites-vous des aspects techniques qui ne rentre pas dans la modélisation ? Index, partitions, ...
C'est ça votre performance ???Citation:
Envoyé par CinePhil
J'ai participé à la numérisation des chèques à la société général en DB2 sur gros système IBM TSP/ISPF en cobol, et ce, avant l'an 2000.
Il y a chaque jours des millions de chèques et l'on archive, sur un minimum de 10 ans.
Le temps de réponse pour la consultation doit être inférieur à la seconde.
Et ce, quelque soit le lieu où se fait la consultation en France !
@+
Il y a une marge entre un Mot_2_Pass de 10 caractères mélangeant lettres capitales et minuscules, chiffres, signes, facile à retenir et rapide à taper, et un_mot_de_passe_qu_on_retient_mais_qui_est_chiant_comme_la_pluie_a_taper (<== 73 caractères) ! :mrgreen:Citation:
Je vous signale que plus le mot de passe est long et plus il est difficile de le cracker. Donc non, cela ne me choque pas.
Et bien si, c'est auto incrémenté. À moins que Worpress ait des ambitions interplanétaires ? :ptdr:Citation:
C'est grand, je le reconnais. Mais rien n'indique que la colonne en question soit auto incrémenté. Si ce type existe, ce n'est pas sans raison.
Et vous vous portez un jugement de valeur sur mon commentaire sans l'avoir étudié ! :aie:Citation:
Vous portez un jugement de valeur sans comprendre la problématique de l'utilisateur qui aura besoin de ce type.
Même avec quelques milliers d'utilisateurs ça fera deux fois plus de place... reportée sur toutes les tables où l'identifiant de l'utilisateur est clé étrangère.Citation:
Oui et alors ? Ce n'est pas parce que vous pouvez mettre 4 milliards d'utilisateurs que cela sera le cas.
On peut vite atteindre des mégaoctets supplémentaires inutiles.
Oui, si vous voulez. C'est un modèle de données non normalisé, aurais-je dû écrire.Citation:
Ce ne sont pas des dénormalisations, c'est du grand n'importe quoi. Nuance.
La dénormalisation a pour but d'améliorer les performances et non le contraire.
Vous chipotez ! Dans mon esprit, le bon modèle de données entraîne déjà une bonne partie de la bonne indexation. Si le modèle est du niveau conceptuel, l'indexation vient évidemment au niveau de la fabrication puis de la maintenance de la BDD et doit aussi être entreprise avec soin.Citation:
N'exagérez pas ! Un modèle de données n'est pas la panacée aux problèmes de performances. Elles y contribuent grandement.
Et que faites-vous des aspects techniques qui ne rentre pas dans la modélisation ? Index, partitions, ...
À noter que des logiciels de modélisation prévoient aussi l'indexation car ils génèrent le code SQL de la BDD. Lorsque je modélise, je pense déjà à l'indexation. J'essaie d'éviter les index inutiles et j'imagine déjà quels seront ceux pertinents à ajouter (notamment les multi-colonnes).
Ce n'était qu'un exemple réalisé avec peu de moyens. J'étais en stage d'ingénieur CNAM dans un service d'analyse de l'INRA à l'époque et la BDD était pour un thésard. Et, de mémoire, le temsp de réponse que j'évoque dépassant la seconde était peut-être sur mon ordinateur portable de l'époque, avant que la BDD fut transférée sur le serveur de développement.Citation:
C'est ça votre performance ???
Bref...
Votre exemple est en effet plus parlant.
Voila pourquoi c'est compliqué pour un débutant en auto-formation... car personne n'est jamais d'accord sur rien lol
Alors c'est pour cela que je pose mes petites questions... et que parfois je les reposes...
Si je pose 3 fois la questions j'ai 3 réponses différentes lol après je fais le tris ;)
La réponse à votre question d'origine est quand même qu'il faut éviter les tables avec beaucoup de colonnes.
En bonus, nous vous conseillons fortement de réaliser un modèle de données normalisé. Ça évitera déjà pas mal de problèmes de performances.
Merci Artemus24 et CinePhil d'avoir des avis et points de vues différents.
Il me reste un dernier point un peu flou
C'est la notion de poids d'une colonne ne servant pas à une recherche.
Si j'ai 1 000 enregistrements avec des colonnes qui contiennent ID : 1ko / Champ1: 1Ko / Champ2 : 2Ko / Champ3: 1Ko / Champ4 : 500Ko
si je veux chercher le CHamp1 de l'ID 1000 -> Msql va devoir charger la table soit (1k0+1ko+1ko+500ko) x 1000 pour chercher l'ID et lire la ligne OU BIEN il ne charge pas la table et se contente de lire la colonne ID et Colonne Champ1 (le champ4 plus lourd n'intervenant pas il n'est pas chargé).
Si le champ4 plus lourd est changé automatiquement avec la table
ne faudrait-il pas séparer les colonnes légères et lourdes MEME si on n'a pas beaucoup de colonnes
ID : 1ko/ IDKEY : 1ko / Champ1: 1Ko / Champ2 : 1Ko / Champ3: 1Ko
IDKEY : 1ko / Champ4 : 500ko
C'est théorique mais c'est pour être sur de comprendre ce que charge Mysql (et comment il le charge, car pour structurer un bdd avant il faut comprendre le mécanisme)
La réponse dépend à la fois de la requête et des index, mais assez peu de la largeur des colonnesCitation:
Envoyé par scamphp
Déjà, interdisez vous les select * dangereux et contre performants, et sélectionnez uniquement les colonnes utiles à votre traitement
Ensuite si vous recherchez la colonne "champ1" que celle ci possède un index filtrant et que le prédicat de recherche (where) est sargable, alors seule la colonne "champ1" participe à la recherche. La requete est donc performante
Ex: select champ2, champ3, champ from ma_table where champ1=@valeur est performant si champ1 est indexé et que cet index est filtrant (le prédicat "égal" étant sargable)
Si on contraire vous cherchez la colonne "champ1" mais que celle-ci ne possède pas d'index, ou que l'index n'est pas filtrant, ou encore que le prédicat de filtrage n'est pas sargable, alors vous allez parcourir séquentiellement la table (ou éventuellement l'index) pour trouver
ex : select champ2, champ3, champ from ma_table where champ1<>@valeur n'est pas performant car le prédicat "différent" n'est pas sargable
Après, toutes choses égales par ailleurs, un index sur une colonne ou combinaison de colonnes large est évidement plus couteux qu'un index sur une petite colonne
Salut CinePhil.
C'est faux, car vous confondez modélisation et aspect technique en vue d'améliorer les performances. Donc non, je ne chipote pas.Citation:
Envoyé par CinePhil
Je ne comprends rien à votre phrase.Citation:
Envoyé par CinePhil
Peut-être tant que l'on reste dans une modélisation standard.Citation:
Envoyé par CinePhil
Mais le rôle du DBA est de s'occuper de tout ce qui est technique, entre autre des performances, de la maintenance, les partitions, les bugs ...
La modélisation répond à un besoin fonctionnel et non technique. Je pense que vous mélangez ces deux notions.Citation:
Envoyé par CinePhil
Ce n'est pas le rôle de la modélisation de penser à des aspects techniques.Citation:
Envoyé par CinePhil
Les bouquins que j'ai sur merise parlent que des aspects fonctionnelles et n'abordent aucun SGBD en particulier.
Vous voulez dire d'un aspect bien plus technique touchant des milliers de personnes en France.Citation:
Envoyé par CinePhil
Je pense que vous mélangez les aspects fonctionnels d'avec les aspects techniques.
En ce qui me concerne, je me suis toujours occupé des aspects techniques car l'utilisateur demande de la performance, en plus de son besoin fonctionnel.
Sinon à quoi peut servir une base de données bien modélisée si les accès sont hyper long ?
Si la modélisation permet de bien concevoir votre base de données, ce n'est pas elle qui va résoudre tous vos problèmes de performances.
Entre autre :
--> les goulots d'étranglements duent au trafic réseau,
--> au nombre d'utilisateurs en parallèle sur une machine,
--> la taille mémoire que le serveur dispose,
--> le paramétrage du SGBD (sérialisation des accès, taille des buffers),
--> du découpage des tables (partitions),
--> de la rapidité des disques durs,
--> de la répartition des partitions sur plusieurs disques afin d'améliorer la rapidité des accès,
--> de la réplications,
--> de la pertinence des index,
--> de la bonne écriture des requêtes,
--> de savoir appliquer correctement le plan d'exécution des requêtes,
--> de réorganiser les tables fréquemment afin de conserver
--> de la reprise en cas de plantage,
--> de la disponibilité du serveur 24H/24H.
C'est un métier (DBA) et cela se fait tous les jours et non pas la modélisation qui se fait en début de projet, et où l'on ne revient plus dessus.
Et une base de données, ça vie, et il arrive parfois qu'il faut changer quelques règles duent à de nouvelles fonctionnalités non prévues au départ, lors de sa conception.
Donc arrêter de dire que tout ce fait dans la modélisation et qu'il le DBA ne fait strictement rien.
@+
Et si on arrêtait cette bagarre stérile et inutile dans une discussion marquée résolue ?
Salut scamphp.
C'est normal car derrière une base de données se cache plusieurs métiers différents.Citation:
Envoyé par scamphp
En ce qui me concerne, je ne m'occupe pas de la modélisation mais plus des aspects systèmes, techniques et performance.
Il faut commencer par le début, à savoir comprendre la fonctionnelle de votre projet.
Ensuite, faire de la modélisation (avec un crayon et du papier).
Puis utiliser un outil qui va vous créer votre modèle conceptuel des données (MCD).
Ensuite passer au modèle logique des données (MLD), autrement dit le choix du SGBD et l'écriture (Data Definition Language) de votre base de données.
Les rêquetes sont faites pour manipuler vos données ( Data Manipulation Language).
Et il y a aussi le modèle conceptuel des traitements, où l'on s'intéresse aux requêtes et aux performances.
Et enfin la maintenance.
Je reconnais que nous nous sommes écartés du sujet initiale.
Pour répondre à nouveau, il faut éviter d'avoir trop de colonnes dans une table.
Evitez d'avoir une longueur de ligne qui dépasse la taille de la page, à savoir 16K (innodb-page-size = 16K).
Et de bien respecter la modélisation qui ne comprend pas que le MCD.
Je ne sais pas pourquoi, tout le monde s'arrête au MCD et oublie très fréquement le MCT.
Cette notion est secondaire si la ligne rentre entièrement dans la page.Citation:
Envoyé par scamphp
Sachez que l'on peut mettre plusieurs lignes dans une page et de ce fait vous avez deux notions, à savoir :
--> la lecture physique (donc de la page),
--> la lecture logique (donc de la ligne),
la première lecture est un accès au disque dur et est très très long.
la seconde lecture se fait en mémoire, c'est-à-dire dans la page stockée en mémoire et est très rapide.
Si votre ligne est à cheval sur deux pages, ce qui peut parfois arriver, vos accès seront donc deux fois plus long que si la ligne est dans une seule page.
Et dans ce cas, la lecture logique et la lecture physique seront identiques.
Inversement, si plusieurs lignes sont dans la même page, par exemple 10 lignes par pages, une lecture physique va correspondre à 10 lectures logiques.
Autrement dit, vos accès seront bien plus rapide.
Hormi cet aspect technique, quand vous faites une clause where dans une requête, les colonnes doivent être indexés. Pourquoi ?
Sans index, le SGBD doit parcourir toutes les lignes de la table avant de trouver la bonne ligne.
Avec un index, il parcourt d'abord celui-ci pour trouver l'adresse physique sur le disque de la page et va ensuite lire physiquement la page.
A votre avis, quel est l'approche la plus performance, lire les pages physiques jusqu'à trouver la bone ligne ou bien parcourir l'index et lire physiquement 1 seule page ?
Ensuite, il y a une façon d'écrire vos requêtes qui ont une influence sur la performance. Voir ce que dit Escartefigue un peu plus bas dans ce sujet.
@+
Je suis désolé après avoir fait une formation sur PHP je pensais que Mysql était un accessoire mais je me rend compte que c'est vraiment quelque chose de primordial et que je vais devoir y consacrer au tant de temps qu'à PHP.Citation:
Evitez d'avoir une longueur de ligne qui dépasse la taille de la page, à savoir 16K (innodb-page-size = 16K).
* La taille de la page ??? c'est quoi une page, c'est le synonyme de table...
* 16k c'est 16ko... n'importe quel contenu texte d'un article fait plus de 16ko
Je suis désolé d'avoir lancé un sujet qui me dépasse
Après je marquerais Résolu pour faire plaisir CinePhil, dont l’obsession est de clore les sujets ;)
MySQL est un système de gestion de bases de données (SGBD) et PHP est un langage de programmation. Ce sont eux choses très différentes.Citation:
Envoyé par scamphp
Une base de données MySQL peut être utilisée par un programme développé en PHP ou n'importe quel autre langage moderne (Java, Python, C#...).
Il existe d'autres SGBD, généralement plus complets et plus performants que MySQL, tels que PostgreSQL, SQL Server, Oracle...
Pour faire vite, c'est une unité d'espace disque lisible en une seule fois par le SGBD. Si une ligne de la table occupe plus de 16 ko et que la taille de la page est de 16 ko, il faudra plus d'une lecture pour lire cette ligne.Citation:
* La taille de la page ??? c'est quoi une page, c'est le synonyme de table...
En considérant qu'un caractère ou un entier simple est codé sur 4 octets, on peut quand même stocker 4000 caractères ou entiers dans 16 ko (c'est pas tout à fait juste mais là aussi c'est pour faire vite)Citation:
* 16k c'est 16ko... n'importe quel contenu texte d'un article fait plus de 16ko
C'est bien de s'intéresser aux bonnes pratiques en matière de BDD avant de se lancer tête baissée dans la réalisation de sa BDD en n'ayant que des connaissances (plus ou moins bonnes) de développeur de programmes.Citation:
Je suis désolé d'avoir lancé un sujet qui me dépasse
La discussion est déjà marquée résolue !Citation:
Après je marquerais Résolu pour faire plaisir CinePhil, dont l’obsession est de clore les sujets ;)
Sans doute parce que votre question initiale a déjà obtenue sa réponse. ;)