,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 ?
Merci
.la communauté d'entraide francophone dédiée au PHP
Champ de type PRIMARY, UNIQUE et INDEX KEY.
Hey ,
Dans le cadre de l'ORM, je me pose 2 ou 3 questions.
Les questions du jour sont :
Merci.
,Dans le cadre de l'ORM, je me pose 2 ou 3 questions.
Les questions du jour sont :
Merci
.« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
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 
) …
) …« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
ViPHP |
5924 Messages
Euh, à priori une clé primaire est unique et indexée, une clé indexée est indexée, une clé unique est unique…
Profil linkedin : http://fr.linkedin.com/pub/emmanuel-thierry/1b/524/630
Profil viadeo : http://www.viadeo.com/fr/profile/emmanuel.thierry4
Profil viadeo : http://www.viadeo.com/fr/profile/emmanuel.thierry4
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 ^^.
C'est un peu minable comme référence car déjà orientée MySQL mais bon … on fait avec ce qu'on a ^^.
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
Mammouth du PHP |
2937 Messages
Dans le manuel de MySQL, on lit ceci :
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.
Sachant qu'une colonne ayant la clé primaire peut être auto-incrémentée, la clé primaire offre l'indexation.Il ne peut y avoir qu'une seule colonne de type AUTO_INCREMENT dans une table, et elle doit être indexée.
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.
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 ...
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.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.
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 …
.Bref, je crois que je vais finir par acheter cette norme ISO parce que ça me faciliterait bien la vie tout de même …
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
Ça dépend des SGBDR, extrait de l'ouvrage "SQL" de Frédéric Brouard chez CampusPress
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.
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.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 :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 :
- 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;
Enfin, la pose d'index ser des colonnes de type "BLOB" est à proscrire absolument. La plupart du temps, les SGBDR ne l'acceptent pas.
- 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).
...
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.
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse 
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à …
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à …
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
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
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