Tout d'abord, attention sur les index sur des colonnes TEXT, ce n'est pas supporté par tout le monde. Je ne sais pas pour sqlite, mais MySQL ne le permet qu'avec un moteur MyISAM.
je ne voyais pas une grosse différence avec une recherche like %tructruc% or like %tructruc%
C'est normal, car dans ce cas, tu n'utilises pas l'index. L'index créé implicitement n'est utilisé que si tu as le début des valeurs contenues dans tes colonnes (càd pas de %pattern% mais des pattern%). Dans ce cas, il faut créer un index full-text, et utiliser les fonctions qui vont avec (cf MATCH pour du MySQL) mais la encore, je renvoie au début de ma réponse: tout le monde ne supporte pas forcément le full-text search.
puisqu'il m'avait semblé comprendre que le concept de bdd c'est que chaque enregistrement (la feuille) est à la même distance du tronc que n'importe quel autre et donc que chercher le mot werrtd va aussi vite que chercher azert et les rentrer dans l'ordre ne change pas grand chose.
Oui, tout est "presque à la même distance" si tu utilises des index. Ce n'est pas du tout vrai sans index.
Certains SGBD permettent d'ordonner ta table, de telle sorte que les nouvelles lignes s'insèrent au bon endroit (pas toujours au tout bas de ta table). Dans ce cas, effectivement, ta table te sert d'index directement, mais ce n'est pas fait sans action de ta part (cf clustered index, avec pas mal de limitations en MySQL).
En fait, je crois que tu penses que quand tu insères une nouvelle ligne dans une table, celle-ci est rangée dans l'ordre alphabétique ou croissant. En vrai, non: ta nouvelle ligne est simplement mise à la fin. Du coup, sans index, tes recherches doivent regarder chaque lignes de la première à la dernière.
Enfin des bases comme mysql sont/étaient(?) pauvres en fonctionnalités par choix de pouvoir traiter rapidement de grosses masse de données, contrairement à certaines autres (oracle,posgresql..) qui pour offrir plus de fonctionnalités avait des temps de recherche moins performant hors tweekenning complexe à mettre en oeuvre et adapté au cas par cas à la suite de tests et tests en tout sens.
Oui, MySQL est toujours assez pauvre, mais ca s'améliore beaucoup avec le temps. Malgré tout, il y aura toujours un fossé entre MySQL et Postgres ou Oracle que tu cites.
Pour les temps de recherche, je ne suis pas d'accord. Globalement ils se valent à peu près (hors tweakening comme tu dis :) sinon MySQL est à la ramasse)
Et pour le adapté au cas par cas, oui, malheureusement, chaque BDD doit être adaptée au cas par cas... Il n'y a jamais de solution universelle.
[^] # Re:
Posté par apkwa . En réponse au message table SQL à optimiser. Évalué à 3.
Tout d'abord, attention sur les index sur des colonnes TEXT, ce n'est pas supporté par tout le monde. Je ne sais pas pour sqlite, mais MySQL ne le permet qu'avec un moteur MyISAM.
C'est normal, car dans ce cas, tu n'utilises pas l'index. L'index créé implicitement n'est utilisé que si tu as le début des valeurs contenues dans tes colonnes (càd pas de %pattern% mais des pattern%). Dans ce cas, il faut créer un index full-text, et utiliser les fonctions qui vont avec (cf MATCH pour du MySQL) mais la encore, je renvoie au début de ma réponse: tout le monde ne supporte pas forcément le full-text search.
Oui, tout est "presque à la même distance" si tu utilises des index. Ce n'est pas du tout vrai sans index.
Certains SGBD permettent d'ordonner ta table, de telle sorte que les nouvelles lignes s'insèrent au bon endroit (pas toujours au tout bas de ta table). Dans ce cas, effectivement, ta table te sert d'index directement, mais ce n'est pas fait sans action de ta part (cf clustered index, avec pas mal de limitations en MySQL).
En fait, je crois que tu penses que quand tu insères une nouvelle ligne dans une table, celle-ci est rangée dans l'ordre alphabétique ou croissant. En vrai, non: ta nouvelle ligne est simplement mise à la fin. Du coup, sans index, tes recherches doivent regarder chaque lignes de la première à la dernière.
Oui, MySQL est toujours assez pauvre, mais ca s'améliore beaucoup avec le temps. Malgré tout, il y aura toujours un fossé entre MySQL et Postgres ou Oracle que tu cites.
Pour les temps de recherche, je ne suis pas d'accord. Globalement ils se valent à peu près (hors tweakening comme tu dis :) sinon MySQL est à la ramasse)
Et pour le adapté au cas par cas, oui, malheureusement, chaque BDD doit être adaptée au cas par cas... Il n'y a jamais de solution universelle.