[SQL] UNIQUE mais pas indéxé

[___seb]

Bijour,

Dans une table mysql je cherche a definir une colonne comme ne pouvant contenir 2 fois la même valeur, je peux donc utiliser la clé UNIQUE mais du coup cette colonne est indéxée; hors je n'ai pas besoin que cette colone soit indéxée (pas de recherche, enfin si juste une qui ne sera pas très fréquente, sur cette colonne) donc je n'ai pas besoin qu'elle soit indéxée.

Peut définir une colonne de cette façon (protégée contre les doublon sans être indéxée) ?

(y aurait-il une erreur sous-jacente dans ma conception ?)

 

[FlorentP]

Pense à ta pauvre base de donnée quand tu va faire un insert ou un update sur ton champs unique : il va devoir se coltiner une recherche sur toutes les données de ta table pour être sur que tu ne cherche pas à aller contre la contrainte d'unicité... d'où certainement l'implémentation "index unique" et pas juste "unique" !

En tout cas l'unicité sans index n'existe pas sur mysql, et n'aurait certainement aucun intéret

 

[julienr]

salut,
sans doute que mysql à besoin de construire un index pour déterminer rapidement si ta valeur n'existe pas déjà sans avoir à parcourir séquentiellement toutes les lignes ?

 

[___seb]

merci de vos reponses.

Donc au dileme
- 1 - Avoir un index_unique (même si il est très peu utiliser (bcp plus de requete) et profiter de la sécurité qui empêche d'avoir des doublons)
- 2 - Ne pas avoir d'index quasi inutile mais ne pas profiter le contrainte d'unicité

Tu (FlorentP) réponds 1.

D'autres avis dans le même sens ? le contraire ? (il vous manque des infos?)

[cite]sans doute que mysql à besoin de construire un index pour déterminer rapidement si ta valeur n'existe pas déjà sans avoir à parcourir séquentiellement toutes les lignes ?[/cite] Si je ne m'abuse, l'index est en mémoire donc c'est plus rapide. Si la valeur est unique, la recherche s'arrête à la première occurence rencontrée donc c'est également plus rapide, je n'ai pas vraiment de doute sur ce point. Mais j'ai peur que ça occupe de la mémoire pour rien, c'est ce qui me fait hésiter...

 

[arnaudmn]

merci de vos reponses.

Donc au dileme
- 1 - Avoir un index_unique (même si il est très peu utiliser (bcp plus de requete) et profiter de la sécurité qui empêche d'avoir des doublons)
- 2 - Ne pas avoir d'index quasi inutile mais ne pas profiter le contrainte d'unicité

Tu (FlorentP) réponds 1.

D'autres avis dans le même sens ? le contraire ? (il vous manque des infos?)

Evidement que c'est le 1. Si tu veux une contrainte pour empêcher les doublons, il FAUT que la base fasse la vérification d'unicité. Et c'est ce que permet un index.
Pour ce qui est de la mémoire, c'est pas un problème. L'index sera chargé en mémoire quand il y en aura besoin. Et un index n'est pas une recopie de la colonne complete en mémoire.

 

[___seb]

Résolu

oki merci à vous