Forum d'entraide PHPFrance

Hey

,

Dans le cadre de l'ORM, je me pose 2 ou 3 questions.
Les questions du jour sont :

une PK (Primary Key, soit clé primaire) est-elle unique et indexée ? ;
une clé unique est-elle indexée ?

Je n'ai pas trouvé ces infos sur Internet …

Merci

.

Une PK est unique, c'est certain.

Indexée, j'aurais tendance à penser que oui, mais je suis moins sûr du lien de cause à effet

J'ai les mêmes questions mais aucunes réponses. Et j'ai pas envie d'acheter la norme SQL 2 (ni la 3 d'ailleurs

) …

Euh, à priori une clé primaire est unique et indexée, une clé indexée est indexée, une clé unique est unique…

Ce qui me fait pensé qu'une clé unique est indexée c'est que PMA (PhpMyAdmin) utilise des boutons radios (et pas des checkboxes) pour gérer ça … Je n'ai pas regardé chez les concurrents.

C'est un peu minable comme référence car déjà orientée MySQL mais bon … on fait avec ce qu'on a ^^.

Dans le manuel de MySQL, on lit ceci :

Il ne peut y avoir qu'une seule colonne de type AUTO_INCREMENT dans une table, et elle doit être indexée.

Sachant qu'une colonne ayant la clé primaire peut être auto-incrémentée, la clé primaire offre l'indexation.

Et MySQL range la clé UNIQUE au nombre de ses index. Après, reste à savoir si cette dernière considération fait partie du standard SQL ou est seulement propre à MySQL.

Vers le quatrième lien de cette page de google tu trouveras la réponse
http://www.google.fr/search?hl=fr&clien ... rt=20&sa=N

A part ça y'a longtemps que je m'étais posé la question et comme toi, après avoir fait choux blanc sur google, j'ai demandé à un copain qui m'a donné la même réponse que Sékiltoyai

Puisque l'indexation consomme des ressources, j'en avais conclu à l'époque qu'une clé unique n'était pas nécessairement indexée (puisque pas toujours nécessaire). Mais ce ne sont que pures spéculations de ma part et j'attends toujours un éclaircissement définitif sur ce point.

J'avais pas vu la réponse de Victor ...

Et MySQL range la clé UNIQUE au nombre de ses index. Après, reste à savoir si cette dernière considération fait partie du standard SQL ou est seulement propre à MySQL.

Oui j'ai lu ça aussi mais pour moi impossible d'en tirer une conclusion claire, bien que cela laisse à penser qu'une clé unique est indexée.

On trouve desfois des résultats à propos de MySQL mais pas sur SQL 2 (le standard quoi) … Et même chez MySQL ce n'est pas claire

.

Bref, je crois que je vais finir par acheter cette norme ISO parce que ça me faciliterait bien la vie tout de même …

Ça dépend des SGBDR, extrait de l'ouvrage "SQL" de Frédéric Brouard chez CampusPress

Les Index
Si les bases de données sont censées masquer les mécanismes internes, la définition même de la notion d'index relève de la cuisine des SGBDR. Cela dit, il est indispensable de défnir des index, car SQL2 ne prévoit rien à ce sujet, même si certains SGBDR créent automatiquement des index sans pour autant vous en avertir.

Un index sert à accélérer les recherches portant sur une ou plusieurs colonnes d'une même table. Du fait des colonnes nécessaires aux jointures des tables, il est indispensable de créer des index sur toutes les colonnes relevant de clefs primaires ou étrangères. Il faut prendre conscience que le mécanisme de jointure est fondé sur une recherche de correspondances de valeurs et nécessite donc la pose d'index pour un traitement rapide de la jointure.

On posera donc des index :

sur toutes les colonnes composant les clés primaires des tables;

sur toutes les colonnes composant les clés étrangères des tables;

sur la plupart des colonnes comportant au moins une contrainte;

sur les colonnes les plus fréquemment sollicitées dans les clauses de filtrage (WHERE et HAVING) des requêtes;
Cependant, un index est un objet coûteux et il est déconseillé de poser des index (et donc de créer des clefs primaires ou étrangères) sur :

des colonnes dont le type est de grande dimension (exemple : CHAR(300));

des colonnes ayant un type de longueur variable (exemple : VARCHAR(32));

des ensembles de colonnes ayant des types très divers (exemple : INTEGER + CHAR(16) + TIMESTAMP + CHAR(12) + FLOAT).
Enfin, la pose d'index ser des colonnes de type "BLOB" est à proscrire absolument. La plupart du temps, les SGBDR ne l'acceptent pas.
...

Autrement dit, il faudra vérifier pour chaque SGBDR sur lequel ton ORM devra travailler pour savoir quels sont les types d'index créés automatiquement ou non.

On sait par exemple pour MySQL qu'un index est automatiquement créé sur une clé primaire. On peut également ajouter un index "INDEX" ou "UNIQUE" sur telle ou telle colonne, y compris pour une clé étrangère où, contrairement à la clé primaire, l'indexation doit être explicite.

Bien, j'ai un peu réfléchit.
Le fait qu'une clé primaire soit unique et indexée, c'est parfaitement logique. Là dessus je n'aurais aucun doute.
Je pense la même chose pour un champ unique. Il doit être forcément être indexé, sinon les performances ne sont pas là. Scanner toute la table serait totalement immonde …

Non ?

Donc on peut imaginer que le standard va dans ce sens.
Je laisse ouvert le sujet s'il y a de nouveaux éléments de réponse.

Édition : répondre à la même minute c'est rare

.
Je me doute bien que ça dépend du SGBD mais j'ai envie de coder selon les standards. Au W3C, il arrive qu'on laisse le choix au navigateur pour l'implémentation. Peut-être qu'ils ont fait pareil ici. Je ne sais pas.
Sinon j'impose un raisonnement selon MySQL et pis voilà …

J'ai réessayé dans php myadmin et effectivement ça affiche un message d'erreur si l'on veux indexer un champs unique et donc logiquement également inversement.

Pour cette version phpMyAdmin - 2.9.1.1 Version du client MySQL: 5.0.22 la cause semble être entendue: un champ unique est indexé.

Y'a quelques années j'avais fait les mêmes manip mais je ne rappelle pas avoir eu les mêmes résultats

Forum d'entraide PHPFrance

Champ de type PRIMARY, UNIQUE et INDEX KEY.

Champ de type PRIMARY, UNIQUE et INDEX KEY.