Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Après une bonne lecture de la documentation j'ai quelques questions à propos de l'optimisation via notamment les index.
1)Lorsque je créer une clé primaire ou secondaire un index unique de type B-tree est créer automatiquement. Les clé étrangère doit-elle
porter un index explicitement pour accélérer les jointures ?
2)Je voudrai faire des recherches sur des prénoms,nom dans ma base de donnée dois-je y déposer un index, si oui de quel type me conseillez-vous ?
3)La recherche plein texte est utile uniquement dans le cas ou l'utilisateur fait de la recherche avec des mots clés ?
4)Un système utilisant l'auto-complétion doit-il être porteur d'un index particulier sur les colonnes parcourut ?
5)Un dernier conseil pour la route ?
Merci.
Hors ligne
1)Lorsque je créer une clé primaire ou secondaire un index unique de type B-tree est créer automatiquement. Les clé étrangère doit-elle
porter un index explicitement pour accélérer les jointures ?
Ça peut être utile. Tout dépend du cas.
C'est quoi un index secondaire ?
2)Je voudrai faire des recherches sur des prénoms,nom dans ma base de donnée dois-je y déposer un index, si oui de quel type me conseillez-vous ?
Encore une fois, ça dépend. Si vous avez vingt lignes de nom/prénom, ça ne servira à rien. Si vous en avez 20 millions, ça devient intéressant... et encore, ça dépend des requêtes.
Quant au type, vous n'avez pas le choix : Btree.
3)La recherche plein texte est utile uniquement dans le cas ou l'utilisateur fait de la recherche avec des mots clés ?
Non, au contraire. Elle est utile quand on cherche des mots et plus exactement leur racine.
4)Un système utilisant l'auto-complétion doit-il être porteur d'un index particulier sur les colonnes parcourut ?
Vous mélangez interface et base de données. Impossible de répondre correctement à une telle question.
5)Un dernier conseil pour la route ?
Lire http://use-the-index-luke.com/fr (ou sa VO http://use-the-index-luke.com).
Guillaume.
Hors ligne
Merci gleu pour votre réponse.
Ça peut être utile. Tout dépend du cas.
C'est quoi un index secondaire ?
Pourriez-vous me dire dans quel contexte vous jugez cela nécessaire ? (Je n'ai pas parler d'index secondaire).
Encore une fois, ça dépend. Si vous avez vingt lignes de nom/prénom, ça ne servira à rien. Si vous en avez 20 millions, ça devient intéressant... et encore, ça dépend des requêtes.
Quant au type, vous n'avez pas le choix : Btree.
Ok je ne pensai pas qu'un index n'étais pas bénéfique qu'à partir de même plus d'un million d'entrée.
Merci pour les autres réponses, je vais suivre votre lien.
Hors ligne
Pourriez-vous me dire dans quel contexte vous jugez cela nécessaire ?
Quand il y a des jointures qui vont récupérer un bon nombre de lignes sur la table de référence par exemple.
Je n'ai pas parler d'index secondaire
En effet, vous avez parlé de clé secondaire. Et du coup, c'est quoi ? 
Ok je ne pensai pas qu'un index n'étais pas bénéfique qu'à partir de même plus d'un million d'entrée.
Le 20 millions était plutôt une façon de dire "un grand nombre de lignes". Dans certains cas, un index sera intéressant même pour un petit nombre de lignes. Mais l'idée est surtout de lire peu de lignes parmi un gros tas de lignes. Et il peut aussi servir pour récupérer les données triées.
Guillaume.
Hors ligne
Merci c'est noté
J’appelle clé secondaire ou clé candidate non primaire un identifiant qui aurait pu être primaire mais ne l'ai pas "immédiatement". Un exemple :
CREATE TABLE T1(
idT1 not null primary key,
....
email not null UNIQUE
);
Suis-je entrain de confondre différentes notions ?
Hors ligne
Si j'ai bien compris, email serait la clé secondaire ? en tout cas, de ce que je comprends de votre explication, vos clés secondaires n'ont aucune existence du côté du SGBD. C'est juste une clé unique, qui est proche d'une clé primaire mais pas identique.
Guillaume.
Hors ligne
en tout cas, de ce que je comprends de votre explication, vos clés secondaires n'ont aucune existence du côté du SGBD. C'est juste une clé unique, qui est proche d'une clé primaire mais pas identique.
Oui c'est bien ça ! Dans un ouvrage que j'ai lu il déclarer les clés secondaire à l'aide du mot clé "UNIQUE" mais je ne sais pas si cette même notion est repris dans PostgreSql. Certains SGBDR y dépose un index non nécessairement unique ce qui reviens à ce que vous avez compris.
Hors ligne
Au niveau de PostgreSQL, une contrainte unique est forcée par un index. La différence avec une clé primaire est qu'une colonne ayant un index unique peut avoir des valeurs NULL, contrairement à une clé primaire.
Guillaume.
Hors ligne
en tout cas, de ce que je comprends de votre explication, vos clés secondaires n'ont aucune existence du côté du SGBD. C'est juste une clé unique, qui est proche d'une clé primaire mais pas identique.
Oui c'est bien ça ! Dans un ouvrage que j'ai lu il déclarer les clés secondaire à l'aide du mot clé "UNIQUE" mais je ne sais pas si cette même notion est repris dans PostgreSql. Certains SGBDR y dépose un index non nécessairement unique ce qui reviens à ce que vous avez compris.
La notion de clef secondaire n'existe pas; On parle de :
clef primaire (NOT NULL et UNIQUE)
clef alternative ou subrogée (UNIQUE et NULLable)
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
La définition de clef alternative que vous donnez ci-dessus est celle que je donne à clé secondaire.
"Le terme de secondaire n'est pas standard. La littérature utilisera le terme de clés candidates pour désigner tous les identifiants d'une table. Un identifiant secondaire est donc une clé candidate non primaire."
Hors ligne
Pages : 1
