Index ou primary

[hm19000]

Bonjour,

j'arrive pas a faire la difference entre index et cle primaire, ou mettre chaqu'une?

Merci

 

[xTrade]

Les clés primaires sont indexées et uniques
Les clés indexées ne sont pas nécessairement uniques

En revanche, j'ai toujours du mal à voir la différence primaire/unique

 

[Marie-Aude]

La clé primaire est "la clé" sur laquelle la table va s'indexer, il peut y avoir plusieurs clés uniques pour un champ, mais une seule clé primaire (qui peut être composée de plusieurs indexes).
Par exemple, un individu peut avoir un numéro d'identification (clé primaire) et un numéro de sécu (clé unique) ou bien un numéro de passeport (clé unique) et un numéro de sécu (clé primaire) ou bien une mère+date de naissance comme clé primaire....

 

[xTrade]

Oui mais les clés uniques sont indexées, non?

 

[erestrebian]

En effet, de même qu'une clé primaire...

Un index sert à trouver plus facilement un résultat mais il ne faut pas le confondre avec la clé primaire qui peut être composée de plusieurs champs...

Souvent un exemple vaut mieux que de longs discours:
Si je veux faire une base de données où je stocke les résultats sportifs je pourrai faire
une table stade avec pour clé primaire identifiant_stade et un index sur le nom du stade pour y accéder plus vite lors d'une requête (je ne mets pas unique parce que plusieurs stades peuvent s'appeler "stade municipal")...
Une table équipe avec pour clé primaire identifiant_equipe et comme clé unique le nom de l'équipe (un nom ne peut correspondre qu'à une seule équipe/je ne le mets pas en index puisqu'il l'ai par défaut)
Une table résultat avec pour clé primaire identifiant_stade, identifiant_equipe_accueil, identifiant_equipe_exterieur, la date et un champs où je marque le résultat (je peux indexer le résultat mais ce ne serait pas vraiment intéressant car ce ne sera pas vraiment un champs sur lequel on fera des recherches)

http://dev.mysql.com/doc/refman/5.0/fr/mysql-indexes.html

 

[Marie-Aude]

Oui mais les clés uniques sont indexées, non?

Automatiquement.

En fait une clé primaire est obligatoirement une clé unique (enfin la combinaison des champs composant la clé primaire) et a obligatoirement un index.
Une clé unique a obligatoirement un index.
Tu peux en plus décider d'indexer un champ qui n'est pas une clé, par exemple le prix dans une base produit, ça le fait assez bien.

 

[hm19000]

D'apres ce que j'ai compris on met un index pour un champs pour y acceder facilement lorqu'on fait WHERE par example.

mais qu'elle est l'interet de la clé primaire?

 

[erestrebian]

Elle permet d'identifier un et un seul n-uple (enregistrement) de la table.

En d'autres termes, j'ai une table d'adhérents, il faut que je puisse reconnaître chaque adhérent séparément. Quels peuvent être les critères me pemettant de savoir qui est qui (d'identifier de manière unique). Le nom? Impossible. Le prénom? L'adresse? Toujours pas. La combinaison des trois? Ce serait envisageable mais pas vraiment optimisé. Le mieux est donc de créer un identifiant (la clé primaire) me permettant de reconnaître chaque personne. Ou comme le disait marie-aude utiliser un n° qui puisse être unique à chaque personne : n° de sécu, n°de passeport... peuvent faire l'affaire pour une personne. Ils ne sont en fait que les identifiants des bases de données de la sécu ou du ministère des affaires étrangères. Dans le cas d'un forum ou d'un catalogue ça devient plus difficile de trouver quelque chose d'autres qu'une clé primaire donnée de façon arbitraire (n°de série).

 

[hm19000]

Je commence a faire la difference, alors je vais vous donnez un table que j'ai sur un de mes site :

id
chanteur
album
date
desc

je classe sur la par d'accueil les 5 derniers albums
Sur une autre page, je trie les albums d'un chanteur
Sur une autre page j'affiche l'album la desc et la date..

Alors

id : clé primaire
chanteur : index
album
date
desc

Est que c juste ?

 

[Antoined]

Pour l'utilisation que tu décris tu n'as pas besoin de mettre un index sur le champ "chanteur". Si tu as un formulaire cela peut-être utile si ce n'est pas le cas évite de faire des requêtes sur des champs texte .

 

[erestrebian]

Pose-toi la question : Est-ce qu'un chanteur peu faire plusieurs albums?

Oui

D'où l'utilité d'une table chanteur (que tu as peut-être déjà) :

id_chanteur
nom
prénom
date_naissance
...


et album :

id_album
id_chanteur (correspond à la clef primaire de la table chanteur)
date
description (desc est un ordre sql à bannir dans les noms de tables, les noms de champs)


Sur ta page d'accueil tu peux appeler les 5 derniers albums en faisant une jointure avec la table chanteur (le point commun est l'id_chanteur).

Ensuite tu peux faire également faire un appel sur une autre page de tous les albums d'un chanteur (toujours sur l'id_chanteur)

Pour la troisième, c'est bon aussi.

Pour approfondir, une clé d'une autre table s'appelle clé étrangère...

 

[hm19000]

j'utilse cette requet pour y acceder au album :

mysql_query("SELECT * FROM gestion WHERE chanteur=\"$art\" AND album=\"$alb\" ");

Antoined as dit d'eviter de faire des requets sur des champs text, alors il est preferable de mettre WHERE id_album=$id

j'utilise ce type de lien http://www.monsite.com/Artiste-nom_arti ... _album.php

comment envoyer id_album sur le lien

j'espere que vous m'avez compris

 

[erestrebian]

MySQL

Exactement!

Comme d'autre part, tu peux récupérer le nom du chanteur grace à une nouvelle requete (avec la table "chanteur" qui me semble indispensable)...

Dans un premier temps, tu peux faire /album.php?id_alb=....&id_art=....

Ensuite, si tu veux faire des urls comme tu as dans ton exemple, il faudrat que tu vois du côté de l'url rewriting...