ПЕРВИЧНЫЕ и INDEX ключи для одного столбца FOREIGN в MySQL - PullRequest
4 голосов
/ 20 января 2010

Я использовал MySQL Workbench для подготовки макета базы данных и экспортировал ее в свою базу данных с помощью phpMyAdmin. Глядя на одну таблицу, я получил следующее предупреждение:

Ключи PRIMARY и INDEX не должны быть установлены для столбца gid

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

Это очень упрощенный пример используемой структуры, которая выдает предупреждение:

CREATE  TABLE IF NOT EXISTS `test_groups` (
  `gid` INT NOT NULL ,
  `gname` VARCHAR(45) NULL ,
  PRIMARY KEY (`gid`) );

CREATE  TABLE IF NOT EXISTS `test_users` (
  `gid` INT NOT NULL ,
  `uid` INT NOT NULL ,
  `name` VARCHAR(45) NULL ,
  PRIMARY KEY (`gid`, `uid`) ,
  INDEX `gid` (`gid` ASC) ,
  CONSTRAINT `gid`
    FOREIGN KEY (`gid` )
    REFERENCES `test_groups` (`gid` )
    ON DELETE CASCADE
    ON UPDATE CASCADE);

edit Я попытался удалить дополнительный индекс для gid в phpMyAdmin, и, похоже, он работает. Каскадное действие по-прежнему происходит при изменении чего-либо в таблице групп, поэтому я предполагаю, что внешнее отношение не нарушается даже без индекса.

Но почему MySQL Workbench заставляет меня сохранять этот индекс? Я не могу удалить его вручную, пока есть внешний ключ.

Ответы [ 2 ]

2 голосов
/ 20 января 2010

Ничего плохого в этом нет. Даже если бы это был весь первичный ключ текущей таблицы, он все еще потенциально корректен. Действительно, если вы не один из тех «программистов», которые когда-либо используют только автоинкрементные столбцы для первичных ключей, вы увидите, что об этом много говорится.

0 голосов
/ 20 января 2010

Я решил эту проблему сейчас. Похоже, что на моем сервере механизм хранения базы данных по умолчанию был настроен на MyISAM, поэтому, поскольку я не указал его явно, все отношения с внешними ключами просто отбрасывались (хотя и не сказав этого). После преобразования его в InnoDB я больше не получаю предупреждение, поэтому кажется, что все работает как надо.

Однако в этом особом случае я буду придерживаться MyISAM и пока оставлю отношения с внешним ключом снаружи, потому что я хочу автоматически увеличивать второй атрибут в этом мультиключе (и это не поддерживается InnoDB), и это немного более полезно для этого приложения, чем наличие внешних ключей (особенно при наличии данных, где обновление и удаление будет выполняться очень редко).

Кроме того, что касается MySQL Workbench, это поведение все еще кажется немного ошибочным, и о нем уже сообщили .

...