Je suis en train de mettre en place une base de donnée (certainement sous MySQL, peut etre PostGreSQL).
Il y aura surtout sur cette base des accès en lecture, et la base est quand même relativement imposante enfin surtout par rapport à ce que j'ai l'habitude de faire) - 6000 enregistrements.
Comment faire pour optimiser la vitesse des requetes sur cette base ? Où mettre des indexs, pourquoi ?
Merci, journal
# Re: SQL & Index
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: SQL & Index
Posté par Fabien (site web personnel) . Évalué à 1.
Et personne n'aurais des URLs vers des documents qui explique comment marche les indexs ?
En gros ça sera un système de recherche multi-critère (c'est ce que l'on m'a dit, j'en serais plus d'ici 2 jours)
merci
[^] # Re: SQL & Index
Posté par Guillaume Lebigot (site web personnel) . Évalué à 1.
J'ai eu l'exemple d'une requête qui mettait plus de 3 à 4 minutes à s'effectuer (sur le serveur, un athlon XP 1800+) alors qu'en fait c'était juste une jointure mal placée...
Bref, pour 6000 enregistrements, à moins de faire tourner ça sur un P200, je ne suis pas sûr si tu devrais te poser ces questions :) Tout devrait bien se passer si tu ne fais pas le boulet sur les requêtes SQL.
[^] # Re: SQL & Index
Posté par Fabien (site web personnel) . Évalué à 1.
Je pense que ça peut quand même apporté encore plus de rapidité les indexs sur la table, non ?
ce n'est pas la seul table du site non plus, et je n'ai pas envie de ralentir tout le site pour une histoire de recherche trop longue...
Dernière question, est-ce que il peut etre utilie pour une table de cette taille là de voir ce que pourrais proposer par exemple un base PostgreSQL ?
[^] # Re: SQL & Index
Posté par Tony GALMICHE . Évalué à 1.
Ma base de données est constituée de 77 tables de plusieurs dizaines de milliers d'enregistrements chacunes (350 000 pour la plus grosse).
Je peux t'assurer que MySQL est la base de donnée la plus rapide en consultation que je connaisse même avec un ordinateur peux puissant (Plus rapide que Oracle, DB2 sur AS400 et Access).
Je suis convaincu qu'avec une table de 6000 enregistrements, tu n'auras même pas besoins de clé, car les résultats seront instantanées.
Par contre, il faudra prévoir des clés, si cettez table doit être reliée à d'autres tables. Il faut prévoir des clés au minimum sur les champs servant aux jointures.
Concernant la documentation, il suffit de taper "mysql sql" sur Google pour être inondée d'informations très interessantes sur le langange sql et les fonctions de MySQL.
Pour finir, il est très facile avec phpMyAdmin de créer, modifier ou supprimer des clés, ce qui te permettra de tester différentes configurations
Bonne continuation.
# Re: SQL & Index
Posté par Hardy Damien . Évalué à 3.
Tu fais un index sur un attribut ou groupe d'attributs qui sert(vent) souvent dans tes criteres de recherche (clause where) avec =, <, > ou between .
à savoir qu'un index mettra plus de temp a l'insertion.
En esperant avoir aidé
Dam
# Re: SQL & Index
Posté par _seb_ . Évalué à 1.
Pour chaque clé (primaire ou secondaire), un index est crée automatiquement.
# Re: SQL & Index
Posté par Fabien (site web personnel) . Évalué à 1.
imaginons que j'ai une liste de personne avec come champ (nom, prénom, ville) et que je fasse des recherches sur la ville de la personne, il faut que je passe la colonne ville en index ?
[^] # Re: SQL & Index
Posté par Dragon . Évalué à 1.
http://www.linuxfrench.net/article.php?id_article=648(...)
Cette série d'article m'a personnelement beaucoup aidé.
Bonne lecture.
[^] # Re: SQL & Index
Posté par Fabien (site web personnel) . Évalué à 1.
[^] # Re: SQL & Index
Posté par DPhil (site web personnel) . Évalué à 1.
SELECT * FROM person WHERE ville='PARIS';
Il vaudra mieux placer un index sur le champs ville.
Si tu as deux tables:
CREATE TABLE person(nom varchar(50), prenom varchar(50), ville int);
CREATE TABLE ville(id int, nom varchar( 50 ));
Tu feras une requête du type:
SELECT * FROM person, ville WHERE ville.id=person.ville AND ville.nom='PARIS'
Tu mettra un index sur l'élément de jointure ville.id (clé primaire d'ailleurs) et person.ville et sur ville.nom
Tout cela est à tester quand ton application sera terminée. Il peut arriver qu'un index ralentisse les requêtes quand il y a de petites tables (peu d'enregistrement)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.