큰 응용 프로그램을 위해 같은 데이터베이스의 다른 스키마에서 테이블에 외래 키를 만드는 것이 좋지 않습니까?

큰 pl / sql 웹 기반 응용 프로그램을 전용 서버로 전송하려고합니다. 이 응용 프로그램은 70 개의 프로그램 코드 패키지가있는 하나의 스키마에 있습니다. 이 응용 프로그램은 다른 시간에 약 15 명 정도를 만들었습니다. 그리고 참조 테이블에 외래 키를 생성하는 것은 다른 스키마의 외래 키를 만드는 것이 일반적인 관행이었습니다. 왜냐하면 동일한 참조 테이블을 다른 스키마에 보관할 필요가 없기 때문에 실제로는 편리하고 데이터베이스를 매우 깨끗하게 유지하기 때문입니다.

그러나 어쨌든 DBA (DB로 새 인스턴스를 생성하고 응용 프로그램을 Solaris 영역 내부에 복사 한 DBA)는 "매우 다른 스키마의 외래 키는 악의적이므로이를 제거해야합니다!"라고 말했습니다. 그는 자신의 관점을 설명하지 않았다.

큰 응용 프로그램으로 그렇게하는 것이 정말 나쁜 생각입니까?

나와 함께-나는 SQL Server에서 왔고 오라클을 싫어하지만 논쟁은 여전히 ​​유효하다고 생각합니다.

스키마는 논리 서브 시스템에서 테이블을 분리하는 것이 좋습니다. 외래 키는 데이터 무결성을 보장합니다. 이것들은 직교적인 개념입니다. 서브 시스템 사이의 데이터 무결성도 반드시 필요합니다. 회계 및 배송 및 중앙 CUstomer 데이터는 고객이 회계에 사용되는 동안 삭제 될 수있는 사일로에 존재하지 않습니다.

따라서 DBA의 요구 사항은 무능력의 징후라고 생각합니다. 누구든지 들어 와서 반론을 할 수있게 해주세요. 나는 행복 할 것입니다. 그러나 이것이 SQL Server에서 수행하는 방법입니다 (여전히 스키마에 대한 정의는 IIRC가 오라클 정의와 거의 다른 것입니다).

세부적인 추론없이 외래 키 제약 조건의 제거를 요구하는 것은 어리석은 일이지만 외부 참조를 제어하는 ​​것이 좋습니다. 참조하는 스키마의 이름이 새 서버에서 다르게 지정되면 어떻게됩니까?

Oracle에서는 현재 스키마 외부에있는 오브젝트에 대한 SYNONYMS를 작성하여이 문제점을 해결합니다.

스키마를 다른 데이터베이스로 이동해야하는 경우 (공간 / 보안 / 무엇이든) 더 이상 참조를 처리 할 수 ​​없습니다. 그것은 아마도 참조를 죽 이도록 요청하는 주된 이유 일 것입니다.

이 작업을 통해 상상할 수있는 유일한 "나쁜 생각"은 REFERENCES 개체 권한 (테이블을 참조하는 제약 조건을 만드는 데 필요한 권한)을 역할에 부여 할 수 없다는 것입니다. 스키마 / 사용자가 스키마 / 사용자를 수행해야합니다.

그 외에도 DBA의 요점을 알 수 없습니다.

자식 테이블 소유자 스키마는 테이블에 레코드를 작성하기 시작하고 부모 테이블 스키마 사용자가 부모 테이블에서 레코드를 삭제하지 못하게합니다. 기대하고 고마워하는 것입니까?