Clé primaire & index ...

Discussion dans 'Web, design' créé par SkYlEsS, 28 Avril 2007.

Statut de la discussion:
Fermée.
  1. Offline
    SkYlEsS Kawai
    Malgré cela, je ne comprends pas bien quand utiliser PRIMARY KEY, INDEX et UNIQUE INDEX ... Quelqu'un pourrait m'expliquer les différences (avec exemples si possible) et les utilités de chacun ?

    Merci :)

    Edit : et pour quel type de champ opter si je veux enregistrer une date complète ? (Jour, mois, année, heure, minute voire seconde)
    SkYlEsS, 28 Avril 2007
    #1
  2. Offline
    Tifox ou pas
    PRIMARY KEY, cela indique que le champs en question est une référence unique pour l'entrée dans la table, donc il est unique sur la table : 2 entrée n'auront jamais un même champs PRIMARY KEY identique, et une tentative d'insérer une entrée avec une valeur de PRIMARY KEY qui existe déjà dans la table échouera. De plus, sur un champs PRIMARY KEY, la base de donnée crée un index qui permet d'accélérer la récupération d'une entrée en donnant sa PRIMARY KEY dans la clause WHERE du SELECT. il n'y a toujours qu'une PRIMARY KEY par table*.

    Si on veut accélerer la récupération d'entrées en fonction de certains champs, on doit construire aussi un index pour ces champs. c'est la qu'intervient la déclaration INDEX et UNIQUE INDEX. Il peut y avoir plusieurs INDEX par table. Si il peut y avoir plusieurs entrées avec une même valeur, tu utilisera INDEX. Par contre, si tu es sur que toutes les entrées auront une valeur différentes, tu utiliseras INDEX UNIQUE. Le point négatif dun INDEX est que ça prend de la place dans la mémoire de la base de donnée.

    Ca c'est la théorie, j'espère que c'est plus claire.


    En pratique maintenant. Quand tu crées une table, tu dois toujours lui donner une PRIMARY KEY (donc un champs qui identifiera de manière unique une entrée).
    Ensuite, si tu fais souvent des SELECT sur les mêmes champs, déclare ces champs comme INDEX ou INDEX UNIQUE, ca accélèrera le SELECT.


    Je te fais un exemple de suite.


    *Il n'y a toujours qu'une PRIMARY KEY par table, mais celle-ci peut être composée de plusieurs champs. Dans ce cas, c'est la combinaison des champs qui la rend unique.
    De la même manière, je pense que tu peux faire un index sur une combinaison de champs.
    Tifox, 29 Avril 2007
    #2
  3. Offline
    Tifox ou pas
    Exemple :

    Imaginons que tu as un table pour une liste de livre, avec comme champs :
    id_livre : un numéro spécifique a ton application pour le livre (unique)
    isbn : numéro ISBN (unique)
    titre :
    auteur :
    nbr_pages : nombre de page

    Ton application propose une recherche par ISBN et par titre, il y aura donc beaucoup de SELECT sur ces champs, ça peut donc être bien de les accélérer avec un INDEX.
    Une fois arrivé dans ton application a la liste des résultats, tu propose pour chaque livre un lien vers une autre page donnant toutes les infos sur le livre. il faut donc passer a cette page un paramètre identifiant de manière unique le livre afin que la page retrouve toutes les infos dans la base de données. on passera donc la PRIMARY KEY.

    Comme PRIMARY KEY, on va utiliser l'id_livre. On aurait pu utiliser l'isbn, mais vu que l'isbn fait partie des caractéristique du livre, j'ai préférer utiliser un numéro propre a l'application qui sera unique (il le sera grace a un AUTO INCREMENT)

    On va mettre un INDEX UNIQUE sur le champs ISBN, et un INDEX sur le titre (le titre n'est pas nécéssairement unique).


    Pour créer ta table, tu aura donc :

    CREATE TABLE liste_livre (
    id_livre int(10) unsigned NOT NULL auto_increment,
    isbn varchar(32) NOT NULL default '',
    titre varchar(127) NOT NULL default '',
    auteur varchar(64) NOT NULL default '',
    nbr_pages int(10) unsigned NOT NULL default 0,
    PRIMARY KEY (id_livre),
    UNIQUE INDEX (isbn),
    INDEX (auteur)
    )
    Tifox, 29 Avril 2007
    #3
  4. Offline
    SkYlEsS Kawai
    D'ors et déjà merci beaucoup de tes explications en tout cas ! :-'
    SkYlEsS, 29 Avril 2007
    #4
  5. Offline
    Tifox ou pas
    De rien, exemple ajouté.
    Tifox, 29 Avril 2007
    #5
  6. Offline
    II phl II Touriste
    Merci je cherchais aussi depuis lgtps une explication simple et précise :-D
    II phl II, 29 Avril 2007
    #6
  7. Offline
    SkYlEsS Kawai
    Youpie, j'ai tout compris ! :cool:

    Mais que veut dire 'unsigned' pour les attributs d'un champ de type int ?

    Sinon, je cherche également de la documentation sur chaque type de champ et quand utiliser tel ou tel type ... Par exemple, dans ce cas, pourquoi utiliser varchar et pas text ? :roll:
    SkYlEsS, 29 Avril 2007
    #7
  8. Offline
    Shrekju ex membre
    Shrekju, 29 Avril 2007
    #8
  9. Offline
    oNi- Elite
    Ca devrait répondre à tes questions : types mysql

    Sinon pour l'exemple, un varchar peut contenir maximum 255 caractères (et on précise la taille à réserver) et un 'text' 65532.
    Quand tu sais que tu dois stocker une valeur qui ne dépassera jamais x caractères, pas la peine de réserver plus. (en gros hein :p).

    EDIT : ha ben grillé :p
    oNi-, 29 Avril 2007
    #9
  10. Offline
    SkYlEsS Kawai
    Quelle différence entre les champs sensibles à la casse et les champs insensibles à la casse ? :-'
    SkYlEsS, 29 Avril 2007
    #10
  11. Offline
    Nikko ...
    Dans un champ sensible à la casse,
    "GamerZ" est différent de "gamerz"

    Dans un champ insensible à la casse, "GamerZ"= "gamerz"

    La casse, ce sont les majuscules.
    Nikko, 30 Avril 2007
    #11
  12. Offline
    SkYlEsS Kawai
    ... au fond, quel est l'intérêt de combiner un index sur plusieurs champs au lieu d'indexer chacun de ses champs ? :)
    SkYlEsS, 1 Mai 2007
    #12
  13. Offline
    Shrekju ex membre
    Si tu fais un index sur plusieurs champs, le 2e sera seulement utilisé si le premier l'est, etc. Donc c'est plus léger de faire un index sur plusieurs champs.
    Shrekju, 1 Mai 2007
    #13
  14. Offline
    Tifox ou pas
    Prenons un exemple : un table contenant comme champs un nom et un prénom.
    Si tu fais souvent une recherche juste sur le nom, tu indexeras le nom.
    Si tu recherche souvent le prénom, tu indexera le prénom.
    Mais si tu recherche en utilisant le nom et le prénom, indexe les 2 ensembles, ce sera plus efficace que d'indexer les deux séparément.
    Tifox, 1 Mai 2007
    #14
  15. Offline
    SkYlEsS Kawai
    Pour enregistrer une date & heure dans la BDD, j'ai le choix entre :

    Soit un champ de type 'int' (unsigned) et d'enregistrer au format date("U") ou time() (une différence entre eux ?).

    Soit un champ de type 'timestamp' (14) et d'enregistrer au bon format. (dans ce cas, c'est quoi la fonction php ou msql pour générer une date à ce format déjà ?)

    Qu'est-ce qui est mieux, le plus rapide, etc. ? :-D
    SkYlEsS, 2 Mai 2007
    #15
  16. Offline
    Froggy fake geek
    ça se sent que les exams arrivent hein ... :D :D
    Froggy, 3 Mai 2007
    #16
  17. Offline
    Bingo Beer Addict
    Pourquoi tu aurais un choix à faire ?
    Si tu enregistres une date et heure, tu enregistres ça au format datetime, c'est tout.
    Pourquoi se compliquer la vie ?
    Bingo, 3 Mai 2007
    #17
  18. Offline
    SkYlEsS Kawai
    ... Je fais des études de langues et littératures françaises et romanes :=)
    SkYlEsS, 3 Mai 2007
    #18
  19. Offline
    SkYlEsS Kawai
    Pour prendre le moins de place dans la BDD et pour avoir une meilleure rapidité ;)
    SkYlEsS, 3 Mai 2007
    #19
  20. Offline
    Bingo Beer Addict
    Commence par choisir le type de données qui correpond vraiment à ce que tu stockes dans le champ, tu t'occuperas de l'optimisation après !!!
    C'est pas les 2 millisecondes que tu gagnerais (si tu les gagnes, ce qui est loin d'être sûr) avec un autre type de données que changeront quoi que ce soit.
    Bingo, 3 Mai 2007
    #20
Statut de la discussion:
Fermée.