2012-05-26 3 views
4

я создаю модель базы данных с Workbench и создать следующую таблицу:Создание внешних ключей на уже проиндексированных столбцов с MySQL Workbench

CREATE TABLE IF NOT EXISTS `Database`.`table1` (
    `idtable1` INT NOT NULL , 
    `uniquecolumn` INT NOT NULL , 
    PRIMARY KEY (`idtable1`) , 
    UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC)) 
ENGINE = InnoDB 

Он имеет первичный ключ и уникальный ключ на моей второй колонке.

При создании внешнего ключа на них, Workbench автоматически добавляет два индекса:

CREATE TABLE IF NOT EXISTS `Database`.`table1` (
    `idtable1` INT NOT NULL , 
    `uniquecolumn` INT NOT NULL , 
    PRIMARY KEY (`idtable1`) , 
    UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) , 
    INDEX `FKOne` (`idtable1` ASC) ,     //here 
    INDEX `FKTwo` (`uniquecolumn` ASC) ,    //(I don't want this!) 
    CONSTRAINT `FKOne` 
    FOREIGN KEY (`idtable1`) 
    REFERENCES `Database`.`table2` (`idtable2`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE, 
    CONSTRAINT `FKTwo` 
    FOREIGN KEY (`uniquecolumn`) 
    REFERENCES `Database`.`table2` (`idtable2`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE) 
ENGINE = InnoDB 

(Выше сценарий вперед спроектированный после добавления внешних ключей к моей модели)

У меня есть четыре индекса.

Это то, что Справочное руководство по MySQL говорит:

В ссылающейся таблице, должен быть индекс, где внешний ключ столбцы перечислены первые столбцы в том же порядке. Такой индекс создается в справочной таблице автоматически, если не существует .

Так что я понимаю, что нет необходимости создавать индексы FKOne и FKTwo, так как уже есть первичный ключ и уникальный индекс, на один и те же столбцы, в том же порядке. Однако MySQL Workbench не позволяет мне удалять индексы FKOne и FKTwo. И я думаю, что смогу это сделать:

CREATE TABLE IF NOT EXISTS `Database`.`table1` (
    `idtable1` INT NOT NULL , 
    `uniquecolumn` INT NOT NULL , 
    PRIMARY KEY (`idtable1`) , 
    UNIQUE INDEX `UniqueIndex` (`uniquecolumn` ASC) , 
    CONSTRAINT `FKOne` 
    FOREIGN KEY (`idtable1`) 
    REFERENCES `Database`.`table2` (`idtable2`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE, 
    CONSTRAINT `FKTwo` 
    FOREIGN KEY (`uniquecolumn`) 
    REFERENCES `Database`.`table2` (`idtable2`) 
    ON DELETE CASCADE 
    ON UPDATE CASCADE) 
ENGINE = InnoDB 

Я прав? Будет ли этот код работать? Есть ли способ сделать это с помощью Workbench? (Помимо удаления этих двух строк в последний момент перед форвардной инженерией).

Возможно, MySQL достаточно умен, чтобы воздерживаться от создания полностью избыточных индексов, и мне не нужно беспокоиться об этом ...?

+0

Действительно ли оба эти столбца ссылаются на один и тот же столбец в одной таблице - или это опечатка? –

+0

Да, они ссылаются на один и тот же столбец в той же таблице, что заставляет меня удалить строку перед обновлением столбца, на который ссылается! Однако это не имеет никакого отношения к этому вопросу. Возможно, я должен был выбрать другой пример. – Dil

+0

Нет, все в порядке. Обычно имеется 2 столбца, ссылающихся на один и тот же - как при определении иерархии parent-child. Уникальные ограничения заставили меня смутиться на мгновение. (и, кстати, у меня были такие же проблемы, с Workbench). –

ответ

2

(я предполагаю, что это при определении модели.)

См Bug 53277, где я упоминаю следующий неясный обходной путь:

Вы начать с внешним ключом и его соответствующий сгенерированный индексом, который вы хотите избавиться. Убедитесь, что ключ (по крайней мере временно) находится в одном столбце, отличном от уникального. На вкладке «Индексы» измените тип на «УНИКАЛЬ». Затем перейдите на вкладку «Столбцы», где теперь проверяется UQ, и снимите флажок. Нежелательный индекс исключается!

+0

Да, вот и все! Большое спасибо!! Я пытался создать внешние ключи, не создавая никаких других индексов, а затем меняя сгенерированные индексы на Unique и Primary. Переход на уникальный был возможен, но не изменился на Primary. Однако ваше решение адаптируется к любой ситуации, поскольку оно полностью удаляет сгенерированный индекс.Меня поражает, что, похоже, это основано на другой ошибке, так как можно было бы ожидать, что снятие столбца UQ приведет к тому, что любой индекс UNIQUE в этом столбце вернется к INDEX, а не исчезнет. – Dil

+0

Теперь я могу поддерживать точную модель базы данных и забыть о редактировании встроенных сценариев. – Dil

Смежные вопросы