[Résolu] Index unique en MySql

Bonjour à tous

J'ai dans ma base MySql une table Programs qui a un champ progID défini comme "index unique"
Dans une autre table Polls il y a un champ pollID défini également comme "index unique"

Je constate que si j'essaie de créer une ligne dans la table Polls avec un champ pollID qui contient la même valeur que le champ progID d'une entrée de la table Programs ça déclenche une erreur sur l'unicité de cette valeur.

Je comprends... que je n'avais rien compris aux index uniques, je les croyais limités à une table, il semble bien que ce ne soit pas le cas.

La raison pour laquelle je déclare ces champs comme "index unique" c'est pour qu'on puisse mettre à jour une ligne plutôt que d'ajouter une nouvelle ligne à la table.

Que dois-je faire pour que ça marche ? Je vais sans doute avoir besoin de revoir tous les index de la base, je ne veux pas tâtonner dans un domaine de ce genre.

Merci de votre aide

Je ne suis pas sûr que ce soit le but de l'index UNIQUE ici. S'il s'agit de mettre en relation deux tables et d'avoir des identifiants qui discriminent les lignes, je verrais plutôt PRIMARY KEY avec AUTO_INCREMENT. Éventuellement avec une vérification sur les clés étrangères. À moins que cela ne réponde à un besoin spécifique ?

(On peut aussi créer un index UNIQUE sur plusieurs colonnes associées d'une même table)

Rodolphe a écrit :

....
(On peut aussi créer un index UNIQUE sur plusieurs colonnes associées d'une même table)

Attention, tu crées un erzats de primary_key.... C'est que l'on appelle une clef composite. Oublie
(Ouais, je sais avec la table de liaison n-n... )
Mais non, oublie. Pourquoi ? 2e forme normalisée/standard d'un SGBDR

wikipedia a écrit :

2FN – Deuxième forme normale
Respecte la deuxième forme normale, la relation respectant la première forme normale et respectant le principe suivant :
Les attributs d’une relation sont divisés en deux groupes : le premier groupe est composé de la clé (un ou plusieurs attributs). Le deuxième groupe est composé des autres attributs (éventuellement vide). La deuxième forme normale stipule que tout attribut du deuxième groupe ne peut pas dépendre d’un sous-ensemble (strict) d’attribut(s) du premier groupe. En d’autres termes : « Un attribut non clé ne dépend pas d’une partie de la clé mais de toute la clé. »

Corollaire : Une relation ayant une clé formée d’un seul attribut est donc en deuxième forme normale.

Le non-respect de la 2FN entraîne une redondance des données qui encombrent alors inutilement la mémoire et l’espace disque.

Modifié par niuxe (01 Sep 2021 - 01:46)

Merci de vos réponses.

Je ne comprends pas grand chose à ce que vous dites.

Comme je l'ai déjà dit sur ce forum j'ai arrêté le de coder de façon professionnelle à peu près au moment où le SGBDR sont sortis des labos où ils se développaient depuis 20 ans en attendant que le prix du CPU et de la mémoire baisse assez pour que ce soit à un prix abordable. Mon travail consistait plutôt à réduire la taille mémoire et l'utilisation du CPU des programmes que j'écrivais tout en faisant des programmes faciles à maintenir.

Posons la question autrement :
Je désire utiliser la requête suivante

INSERT INTO Table
    .......
ON DUPLICATE KEY UPDATE 
    .........
;

Pour ce faire il faut bien qu'il y ait une clef unique qui déclenche la mise à jour au lieu de la création d'une ligne.

J'ai bien dans chaque table une PRIMARY KEY auto indent que j'appelle systématiquement "id" dans toutes mes tables.

Pour faire cela avec "id" il faudrait que je retrouve la valeur de cette clé, c'est à dire faire un

SELECT id
    FROM Table
    WHERE le champ qui  m'intéresse = la valeur de ce champ
;

et ensuite faire un INSERT si id est nul ou un UPDATE sinon.

Ma compréhension de béotien c'est que les clés uniques ont justement cette fonction qui permet de simplifier le code, en plus d'accélérer la recherche des entrées dans la table.

S'il existe une autre façon de faire ça prière de m'expliquer comment.

Remarque: si on veut vraiment réduire la taille des données, on utilise une base de donnée hiérarchique, mais ça nécessite de savoir ce qu'on veut faire de ces données, ce qui n'est pas ce pourquoi sont faites les bases de données relationnelles.
Modifié par PapyJP (01 Sep 2021 - 21:52)

Et l'eau,

désolé du temps de réponse. Le problème étant que je ne vois pas ton contexte. As tu un schemas de ta db ?

Merci de ta réponse
Le schéma est trop gros pour que je puisse aisément le joindre.
Le problème que j’ai signalé n’est pas réapparu.
Ça doit être un effet de bord dans la commande SQL
Pour l’instant je laisse tomber.