외부 키 제약 조건:업데이트 시 및 삭제 시 사용 시기

외부 키 제약 조건:업데이트 시 및 삭제 시 사용 시기

MySQL Workbench를 사용하여 데이터베이스 스키마를 설계하고 있습니다.이것은 그림을 그릴 수 있고 변환이 가능하기 때문에 매우 멋집니다.p

어쨌든 저는 해외 키 지원 때문에 InnoDB를 사용하게 되었습니다.단, 외부 키의 [업데이트 시]와 [삭제]옵션을 설정할 수 있습니다."Restrict", "Cascade" 및 set null을 간단한 예에서 사용할 수 있는 위치를 설명해 줄 수 있습니까?

예를 들어, I have a new from a new first.user을 포함한 테이블userID메시지 테이블이 있다고 칩시다.message이는 2개의 외부 키(같은 프라이머리 키 참조)를 가진 다대다입니다.userID에서user표)를 참조해 주세요.이 경우 업데이트 시 및 삭제 시 옵션을 설정하는 것이 도움이 됩니까?그렇다면 어떤 것을 선택해야 합니까?만약 이것이 좋은 예가 아니라면, 어떻게 이것이 도움이 될 수 있는지 좋은 예를 제시해 주시겠습니까?

감사해요.

데이터베이스에 제약을 가하는 것을 주저하지 마십시오.일관성 있는 데이터베이스가 있어야 하며, 이것이 데이터베이스를 사용하는 좋은 이유 중 하나입니다.특히 이를 요구하는 애플리케이션이 여러 개 있는 경우(또는 하나의 애플리케이션만 있지만 직접 모드와 서로 다른 소스를 사용하는 배치 모드 포함).

MySQL에서는 postgre와 같은 고도의 제약이 없습니다.SQL이지만 적어도 외부 키 제약 조건은 상당히 고급입니다.

예를 들어 회사 테이블을 예로 들겠습니다.사용자 테이블에는 이들 회사의 사람이 포함되어 있습니다.

CREATE TABLE COMPANY (
     company_id INT NOT NULL,
     company_name VARCHAR(50),
     PRIMARY KEY (company_id)
) ENGINE=INNODB;

CREATE TABLE USER (
     user_id INT, 
     user_name VARCHAR(50), 
     company_id INT,
     INDEX company_id_idx (company_id),
     FOREIGN KEY (company_id) REFERENCES COMPANY (company_id) ON...
) ENGINE=INNODB;

ON UPDATE 조항을 살펴보겠습니다.

• ON UPDATE RESTRICT : 기본값: COMPANY 테이블에서 company_id를 업데이트하려고 하면 적어도 한 명의 사용자가 이 회사에 링크되어 있으면 엔진은 작업을 거부합니다.
• 업데이트 시 No ACTION : RESTRICT와 동일합니다.
• ON UPDATE CASCADE : 보통 가장 좋은 것 : COMPANY 테이블의 행에서 company_id를 갱신하면 엔진은 이 회사를 참조하는 모든 USER 행에 따라 갱신합니다(그러나 USER 테이블에서 트리거가 활성화되지 않음, 경고).엔진이 변화를 추적해 줄 거예요, 좋아요.
• ON UPDATE SET NULL : COMPANY 테이블의 행에서 company_id를 갱신하면 엔진은 관련된 USER company_id를 NULL로 설정합니다(USER company_id 필드에서 사용할 수 있어야 합니다).저는 업데이트에서 그것에 대해 재미있는 것을 볼 수 없지만, 제가 틀릴 수도 있습니다.

이제 ON DELETE 측에서 다음을 수행합니다.

• ON DELETE RESTRICT : 디폴트 :COMPANY 테이블에서 company_id ID를 삭제하려고 하면 이 회사에 적어도 한 명의 사용자가 링크를 걸면 엔진이 작업을 거부합니다.
• 삭제 시 액션 없음: RESTRICT와 동일
• DELETE CASCADE : dangerous :테이블 COMPANY에서 회사 행을 삭제하면 엔진은 관련된 사용자도 삭제합니다.이것은 위험합니다만, 세컨더리 테이블의 자동 청소에 사용할 수 있습니다(따라서 원하는 것이 될 수 있지만, 회사에서는 확실히 그렇지 않습니다).< - > USER의 예
• DELETE SET NULL : full : COMPANY 행을 삭제하면 관련 사용자는 자동으로 NULL과 관련지어집니다.NULL이 회사가 없는 사용자의 값인 경우, 예를 들어 일부 콘텐츠의 작성자로서 사용자를 응용 프로그램에 계속 포함시켜야 하지만 회사를 삭제하는 것은 문제가 되지 않습니다.

통상, 디폴트는 「ON DELETE RESTRICT ON UPDATE CASCADE With Some」입니다.ON DELETE CASCADE 테이블및 '모든 로그'에 ON DELETE SET NULL마스터 테이블이 USER 테이블의 JOB 테이블과 같이 외부 키가 포함된 테이블의 '단순 속성'인 경우.

편집

저 그거 안 쓴 지 오래됐어요.이제 한 가지 중요한 경고를 추가해야 할 것 같습니다.MySQL에는 캐스케이드에 관한 큰 제한이 있습니다.캐스케이드는 트리거가 아닙니다.따라서 해당 엔진에서 트리거를 사용할 만큼 자신감이 넘치는 경우에는 캐스케이드 제약을 피해야 합니다.

• http://dev.mysql.com/doc/refman/5.6/en/triggers.html

MySQL 트리거는 SQL 문에 의해 테이블이 변경된 경우에만 활성화됩니다.뷰 변경이나 MySQL Server에 SQL 문을 전송하지 않는 API에 의해 작성된 테이블 변경에는 활성화되지 않습니다.

• http://dev.mysql.com/doc/refman/5.6/en/stored-program-restrictions.html#stored-routines-trigger-restrictions

==> 마지막 편집 내용을 참조하십시오. 이 도메인에서 작업이 진행 중입니다.

트리거는 외부 키 액션에 의해 활성화되지 않습니다.

그리고 나는 이것이 언젠가 고쳐질 것이라고 생각하지 않는다.외부 키 제약 조건은 InnoDb 스토리지에 의해 관리되며 트리거는 MySQL SQL 엔진에 의해 관리됩니다.둘 다 떨어져 있어요.Innodb는 제약 관리 기능이 있는 유일한 스토리지입니다. 언젠가 스토리지 엔진에 직접 트리거를 추가할 수도 있고 그렇지 않을 수도 있습니다.

단, 트리거 구현이 불충분한 것과 매우 유용한 외부 키 제약 지원 중 어떤 요소를 선택해야 하는지에 대해서는 제 의견을 가지고 있습니다.데이터베이스의 일관성에 익숙해지면 Postgre가 마음에 듭니다.SQL.

2017년 12월 - MySQL에 대한 이 편집 업데이트:

@IstiaqueAhmed가 코멘트한 바와 같이, 이 문제에 대해서는 상황이 바뀌었습니다.따라서 링크를 참조하여 실제 최신 상태(향후 다시 변경될 수 있음)를 확인하십시오.

어플리케이션의 맥락에서 이 점을 고려해야 합니다.일반적으로 데이터베이스가 아닌 응용프로그램을 설계해야 합니다(데이터베이스는 응용프로그램의 일부일 뿐입니다).

다양한 케이스에 대해 어플리케이션이 어떻게 대응해야 하는지 고려합니다.

디폴트 액션은 조작을 제한(즉, 허가하지 않음)하는 것입니다.이는 보통 멍청한 프로그래밍 오류를 방지하기 위해 필요한 것입니다.단, DELETE CASCADE에서도 도움이 됩니다.실제로 응용 프로그램과 특정 개체를 삭제하는 방법에 따라 달라집니다.

개인적으로 InnoDB는 FK 제약이 있기보다는 데이터를 폐기하지 않기 때문에 사용합니다(C.f. MyISAM, 즉 폐기).

@MarkR 답변에 덧붙여 주의할 점은 ORM을 사용하는 많은 PHP 프레임워크가 고급 DB 셋업(외부 키, 계단식 삭제, 고유 제약)을 인식하지 않거나 사용하지 않는다는 것입니다.이 경우 예기치 않은 동작이 발생할 수 있습니다.

를 들어, ORM "ORM"을 ,DELETE CASCADE는 관련 테이블의 레코드를 삭제합니다.ORM이 관련 레코드를 삭제하려고 하면 오류가 발생합니다(종종 자동으로).

언급URL : https://stackoverflow.com/questions/6720050/foreign-key-constraints-when-to-use-on-update-and-on-delete