다른 스키마의 테이블 열을 참조하여 내 테이블 중 하나에 외래 키를 만들려고했습니다. 그런다른 스키마의 테이블에 대한 외래 키 참조
뭔가 : 내가 필요한 보조금을 가지고 있기 때문에
ALTER TABLE my_schema.my_table ADD (
CONSTRAINT my_fk
FOREIGN KEY (my_id)
REFERENCES other_schema.other_table(other_id)
)
,이 괜찮 았는데.
이제 다른 스키마의 테이블을 참조하지 않거나주의해야 할 사항이 있는지 궁금합니다.
아무 문제가 없습니다. 스키마는 테이블 간의 외래 키 관계를 설정할 때 실제로 아무런 영향을 미치지 않습니다. 적절한 사람이 사용하려는 스키마에 필요한 권한을 가지고 있는지 확인하십시오.
이 문제가 발생할 수있는 한 가지 이유는 올바른 순서로 삭제하는 데주의해야한다는 것입니다. 이것은 테이블에 고아가없는 것이 얼마나 중요한지에 따라 좋거나 나쁠 수 있습니다.
이것은 자체 스키마의 테이블을 참조하는 외래 키와 정확하게 동일하게 작동합니다.
부모 키가 항상 업데이트되거나 부모 테이블에서 항목을 삭제하는 경우 일반 외래 키와 마찬가지로 my_id을 인덱싱하는 것을 잊지 마십시오. 인덱싱되지 않은 외래 키는 대규모 경합의 원인 일 수 있으며 인덱스는 일반적으로 유용합니다 어쨌든).
내가 만난 유일한 것은 다른 스키마에 대한 권한이 있는지 확인하는 것이 었습니다. 평소의 것들 - 그러한 허가가 어떤 이유로 든 사라지면, 그것에 대해 듣게 될 것입니다.
다른 사람들이 다른 스키마에 대한 권한을 가진 조직에 있다면 다른 스키마에 제약 조건을 해제하거나 삭제하고 재 작성하는 기능을 부여하는 것이 좋습니다.
예를 들어, 테이블을 삭제하거나 자르고 다시로드하여 일부 (매우 이상한) 지원 문제를 처리해야 할 수 있습니다. 한밤중에 전화하지 않으려는 경우 일시적으로 제약 조건을 제거 할 수있는 권한을 부여하는 것이 좋습니다. (외부 제약 조건이 비활성화되거나 삭제되는지 여부를 알 수 있도록 자체 경고를 설정하는 것도 좋습니다.) 조직/스키마 라인을 넘을 때는 다른 사람들과 잘 놀고 싶어합니다. 빈센트가 언급 한 지수는 그것의 또 다른 부분입니다.
글쎄, 내 스키마의 테이블을 참조 할 때도 마찬가지입니다. 권리? –
예, 동일합니다. 조심해야 할 것이 있습니다. –