는 MySQL의 워크 벤치

내가 워크 벤치로 데이터베이스 모델을 생성하고 다음 표를 작성하고 함께 이미 인덱스 컬럼에 외래 키를 생성.는 MySQL의 워크 벤치

내가 그들에 외래 키 제약 조건을 생성, 워크 벤치가 자동으로 두 개의 인덱스를 추가합니다

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은 완전히 중복 된 인덱스를 만들지 않아도 될만큼 똑똑하기 때문에 걱정할 필요가 없습니다 ...?

출처

2012-05-26 Dil

두 열 모두 실제로 동일한 테이블의 동일한 열을 참조합니까? 아니면 오타가 있습니까? –

예, 동일한 테이블에서 동일한 열을 참조하므로 참조 된 열을 업데이트하기 전에 행을 삭제해야합니다! 그러나이 질문과는 아무런 관련이 없습니다. 어쩌면 다른 예를 선택해야했을 것입니다. – Dil

아니요, 괜찮습니다. 부모 - 자식 계층을 정의 할 때처럼 2 개의 열이 동일한 열을 참조하는 것이 일반적입니다. 고유 한 제약 때문에 잠시 혼란스러워졌습니다. (그리고 그런데, 나는 Workbench와 동일한 문제도 가지고 있었다). –

(모델을 정의 할 때 나는이되어 있으리라 믿고있어.)

을 나는 다음과 같은 모호한 해결 언급 Bug 53277, 참조 :

당신은 외래 키와 함께 시작하고 당신이 원하는 생성 된 색인 대응을 제거하기 위해. 고유하지 않은 단일 열에 키가 (최소한 일시적으로) 있는지 확인하십시오. 색인 탭에서 유형을 고유로 변경하십시오. 그런 다음 UQ가 선택되어있는 열 탭으로 이동하여 선택을 취소하십시오. 원치 않는 색인이 제거되었습니다!

출처

2012-06-09 00:08:57 usethe4ce

예, 그게 전부입니다! 대단히 감사합니다 !! 먼저 다른 인덱스를 작성하지 않고 생성 된 인덱스를 고유 및 기본으로 변경하지 않고 외래 키를 작성하려고했습니다. 고유로 변경은 가능했지만 기본으로 변경되지 않았습니다. 그러나 생성 된 인덱스를 완전히 삭제하므로 솔루션은 모든 상황에 적응합니다.나에게 충격을주는 것은 다른 버그에 기반한 것으로 보인다. uncheking UQ 열이 해당 열의 UNIQUE 인덱스가 INDEX로 돌아가서 사라지지 않을 것으로 예상하기 때문이다. – Dil

이제 데이터베이스의 정확한 모델을 유지 관리하고 앞으로 제작 된 스크립트 편집을 잊어 버릴 수 있습니다. – Dil

는 MySQL의 워크 벤치

답변

관련 문제