Discussion :

[jimmo]

Bonjour,

J'ai un espace membres.
une personne ouvre un compte (chef d'équipe). L'id_equipe est la valeur de l'id_user du chef d’équipe. Il ouvre ensuite jusqu'à 5 comptes(coéquipier) qui prennent en valeur id_equipe la valeur de l'id_user du chef d’équipe.
La raison à cela est que le chef d'équipe a accès à toutes les infos de tous ses membres. Chose qui n'est pas possible pour les membres qui n'ont accès qu'à leurs informations.
Ci-dessous, une partie de ma bdd.
Le chef d’équipe va créer ses fournisseurs, les catégories, les produits. et chacun des coéquipiers va créer ses contacts.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
user: id_user, id_equipe, nom_user, prenom_user........
contacts: id_contact, id_user, id_equipe, nom_contact, prenom_contact......
fournisseur: id_fourn, id_user, id_equipe, nom_fourn.....
categorie: id_cat, id_equipe, nom_cat
produit: id_prod, id_equipe, id_cat, nom_prod, ref_prod, ht_prod
bdc: id_bdc, id_equipe, id_produit, qte_prod, ht_bdc, num_bdc....
mail: id_mail, id_user_exp, id_user_dest, mess_mail, lu_mail
agenda: id_agenda, id_user, id_equipe, debut_agenda, fin_agenda, mess_agenda

Je cherche à comprendre l’intérêt des index dans la conception de ma bdd.
Sachant que les index peuvent ralentir les requêtes de INSERT, UPDATE ou DELETE. Et que dans mon cas, il y a autant de modifications que de simples lectures.
Sur quelles colonnes à votre avis est il intéressant de mettre un index.
Merci de votre aide et explication.

[Antoun]

Les index n'ont aucun rôle dans la conception. Il s'agit simplement d'optimiser sans modifier la conception.

Tout dépend des volumes et de la sélectivité, mais globalement les index vont ralentir marginalement les requêtes de modification (qui portent le plus souvent sur une seule ligne) et accélérer spectaculairement les requêtes de sélection (qui doivent fouiller dans l'intégralité des tables).

En première approche, tu dois indexer toutes les colonnes de jointures, ainsi que celles sur lesquelles il y aura fréquemment des filtres, surtout des filtres très sélectifs. Par exemple, trouver un 'jimmo' parmi 100 000 abonnés est un filtre très sélectif, pour lequel l'effet de l'index sera spectaculaire. A l'inverse, filtrer sur le sexe parmi une population à peu près équilibrée est peu sélectif, l'index serait inutile voir contre-productif (en vérité, MySQL n'utilise normalement pas les index si la sélectivité estimée est supérieure à 30%).

[aieeeuuuuu]

Bonjour,

En fait, je dirai plutôt que les index vont même certainement améliorer les performances pour les update et delete, surtout dans votre cas.

Comme l'a indiqué Antoun, les index sont a voir bien après a modélisation, qui elle en revanche doit être bien soignée, vous n'avez pas indiqué votre besoin, mais j'ai l'impression qu'il y aurait des choses à revoir dans votre modèle.

[Antoun]

En fait, je dirai plutôt que les index vont même certainement améliorer les performances pour les update et delete, surtout dans votre cas.

aieeeuuuuu a raison, car la base va plus facilement trouver les lignes à modifier ou supprimer.

[jimmo]

Merci de votre participation,
je vais donc indexer id_user et id_equipe.
Je dois aussi indexer toutes les jointures?
Et lorsque je lis partout que les index ralentissent les opérations de modification de la table(en particulier insert et delete car la table d'index doit se remettre à jour), on parle de quel genre de ralentissement?

[Antoun]

Merci de votre participation,
je vais donc indexer id_user et id_equipe.
Je dois aussi indexer toutes les jointures?

Sauf celles dont tu préfères qu'elles soient lentes

Et lorsque je lis partout que les index ralentissent les opérations de modification de la table(en particulier insert et delete car la table d'index doit se remettre à jour), on parle de quel genre de ralentissement?

Le genre négligeable.

En fait, tout est une question de type d'utilisation. En utilisation classique (on va dire OLTP), tu vas insérer une ligne à la fois. Mettons que l'insertion dure deux millièmes de seconde sans index, et quatre millièmes avec index. Proportionnellement, c'est un ralentissement important. Concrètement, deux millièmes de secondes en plus, ça n'a pas la moindre importance par rapport à ce que ça va permettre de gagner en performance de restitution.

Dans des utilisations de données en masse, type OLAP, là oui, ça commence à avoir du sens de dire que les index ralentissent l'insertion. Si tu insères un million de lignes en 5 minutes et que l'index te fais passer à 10 minutes, ça commence à poser problème. En général, on désactive l'index avant l'insertion de masse pour le reconstruire après l'insertion, c'est beaucoup plus rapide. C'est aussi plus logique : s'il y a un million d'insertions, ça ne sert à rien de les tracer une par une, autant attendre le résultat final et le ré-indexer.

Je précise que mes chiffres ne s'appuient sur rien, c'est juste pour illustrer l'idée.

[jimmo]

Je te remercie, tout est très clair maintenant. Je m'y mets et reviendrai en cas de soucis
Merci et bonne journée

[escartefigue]

une personne ouvre un compte (chef d'équipe). L'id_equipe est la valeur de l'id_user du chef d’équipe. Il ouvre ensuite jusqu'à 5 comptes(coéquipier) qui prennent en valeur id_equipe la valeur de l'id_user du chef d’équipe.

Et que se passera -t- il si l'équipe change de chef d'équipe ? ou que temporairement, une équipe n'ait pas de chef ?
Il serait nettement préférable d'attribuer à l'équipe son propre identifiant, et de modéliser une relation à date entre une équipe et une personne, matérialisant ainsi un ou plusieurs chefs d'équipe successifs.