Discussion :

[dighan]

Bonjour,

J'utilise MySQL Workbench et lorsque j'exécute mes instructions DDL j'obtiens l'erreur suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
#1005 - Can't create table './products.frm' (errno: 121)

Ci-dessous une description de mes tables (categories, sections, products) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
CREATE  TABLE IF NOT EXISTS `categories` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(80) NOT NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
CREATE  TABLE IF NOT EXISTS `sections` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `category_id` INT UNSIGNED NOT NULL ,
  `name` VARCHAR(80) NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `fk_categories` (`category_id` ASC) ,
  CONSTRAINT `fk_categories`
    FOREIGN KEY (`category_id` )
    REFERENCES `categories` (`id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
CREATE  TABLE IF NOT EXISTS `products` (
  `id` INT UNSIGNED NOT NULL AUTO_INCREMENT ,
  `category_id` INT UNSIGNED NOT NULL ,
  `section_id` INT UNSIGNED NOT NULL ,
  `created_at` DATETIME NOT NULL ,
  `label` VARCHAR(100) NOT NULL ,
  PRIMARY KEY (`id`) ,
  INDEX `fk_categories` (`category_id` ASC) ,
  INDEX `fk_sections` (`section_id` ASC) ,
  CONSTRAINT `fk_categories`
    FOREIGN KEY (`category_id` )
    REFERENCES `categories` (`id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_sections`
    FOREIGN KEY (`section_id` )
    REFERENCES `sections` (`id` )
    ON DELETE CASCADE
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

J'ai parcouru plusieurs forums et ce problème survient généralement lorsque le type de la clé de référence et celui de la clé étrangère sont différents. Malheureusement pour moi, il ne s'agit pas de ça. J'ai peut être mal organisé/conçu mes tables.

Quelqu'un a-t-il déjà eu ce problème ou dans le meilleur des cas sait comment le résoudre ?

D'avance merci pour votre aide,

Yvan

[dighan]

J'ai beau supprimer les indexes, renommer les contraintes, rien n'y fait, l'erreur est toujours là !

[CinePhil]

Bien entendu, les tables sont créées dans le bon ordre : categories puis section puis products ?

Puisqu'une section est rattachée à une catégorie, il me semble inutile de mettre la clé étrangère catégory_id dans la table products.
Si je supprime cette clé étrangère, la création de la table fonctionne.

[dighan]

Puisqu'une section est rattachée à une catégorie, il me semble inutile de mettre la clé étrangère catégory_id dans la table products.

Oui, la présence de la colonne CATEGORY_ID est discutable. Je l'avais ajouté pour pouvoir localiser plus rapidement mon enregistrement PRODUCT (évite les jointures). C'est une pratique que j'ai toujours appliqué, peut-être que je me trompe...

Oui tu te trompes !
Tu crées une redondance de données inutile et qui peut entraîner des incohérences telles que l'affectation à un produit d'une catégorie non rattachée à la section du produit.
Il ne faut pas avoir peur des jointures, les SGBDR sont fait pour ça.
Et comme tu as correctement indexé tes tables, tu ne devrais pas rencontrer de soucis de performances avant plusieurs millions de produits répartis dans beaucoup de sections pour pas mal de catégories.

Pour résoudre ce problème, j'ai tenté de simplifier au maximum mes requêtes (pas forcément les meilleures optimisations),

Et là comme par magie tout fonctionne. Peut être qu'un indexe ne supporte pas le type UNSIGNED. J'ai fouillé sur la doc MySQL et ça ne semble pas être ça.

Euh... non, je n'ai jamais eu de problème avec UNSIGNED que j'ai utilisé pourtant plusieurs fois.
Essaie de changer le type en UNSIGNED maintenant pour voir ?

Quoique je trouve ça bizarre sur le plan du fonctionnement du SGBD, je pense que la suppression de la clé étrangère uniquement suffise à résoudre le problème efficacement.