스키마를 과도하게 사용하거나 올바르게 사용합니까?

Stackoverflow 에서이 질문을 한 후에 , 내가 한 일이 정확하고 최선의 방법인지 궁금했습니다.

기본적으로 내가 만드는 모든 객체는 사용법을 반영하는 스키마 이름을 가진 스키마로 이동합니다. 예를 들어, 나는 스키마 Audit와 Admin(다른 것들 중에서)를 가지고 있습니다.

이것에 객체가 남지 않습니다 dbo. 이거 괜찮아? 내가해야 할 다른 일이 있습니까?

스키마는 훌륭한 보안 도구 일뿐 아니라 사용하기에 충분한 이유 일뿐 아니라 논리적 분리에도 완벽합니다. 그리고 이것이 당신이 연습하고있는 것처럼 보입니다.

현재 요구 사항에 특별한 보안이 필요하지 않더라도 감사와 관련된 모든 데이터베이스 개체는 데이터베이스 역할에 안전해야합니다. 이러한 개체가 dbo스키마 전체에 흩어져 있으면 deny개별 개체에 대한 명시적인 권한 이 있어야 합니다. 그러나 Audit스키마를 사용하면 단일 작업을 수행 deny하고 설정됩니다.

저는 개인적으로 스키마 사용을 연습합니다. 그러나 데이터베이스의 모든 것과 마찬가지로 행복한 매체가 있습니다. 데이터 계층의 각 세부적인 측면에 대한 스키마를 만들지 않습니다. 스키마와 분리가 너무 많습니다. 그러나 나는 당신이 그 근처에 있지 않다고 생각합니다.

전형적인 패턴은 권한에 따라 스키마, 그래서 당신은 할 것 WebGUI, Desktop모든 오브젝트가 같은 permissons 그래서 코드 등 스키마에서를 .

명확한 사용자 그룹이 있다면 그에 대한 권한을 부여 할 수 있지만 어느 시점에서 겹치거나 지저분한 권한이 생길 수 있습니다. 권한 개체가 아닌 코드 내부의 일부 검사로 사용자 / 그룹 검사를 연기하는 경향이 있습니다. 관리자 및 HR Excel 사용자가 있다고 가정하십시오. 이러한 Desktop코드는 모두 실행 코드입니다.

데이터는 일반적으로 공유되므로 Data스키마 History또는 Archive스키마가 있습니다.

일부 코드는 UDF 또는 내부 프로세스와 같이 공개 Helper되지 않으므로 클라이언트 코드로 실행해서는 안되는 코드에 스키마를 사용합니다 .

마지막으로, 스키마 좋아 Staging하거나 System또는 Maintenance유용한 가끔 있습니다.

dbo스키마 에는 사용자 개체가 없지만 dbo모든 스키마를 소유합니다.

dbo스키마의 어떤 개체 도 완벽 하지 않습니다 . 내가 볼 수 있듯이 스키마를 과도하게 사용하지는 않습니다. 얼마나 많은 스키마가 '너무 많은가'는 상당히 주관적인 질문이지만 ( 'OO 디자인에 몇 개의 클래스가 있어야합니까?'와 비교할 수 있습니다).

내가 언급 한 유일한 다른 것은 개별 객체가 아닌 스키마에 대한 권한을 부여하는 것입니다 (SO 질문은 권한에 대해 아무것도 지정하지 않습니다).

모듈과 사용 패턴에 따라 스키마를 사용하여 데이터베이스를 분리하고 싶습니다. 데이터베이스 테이블을 이해하기가 매우 쉬워서 유지 관리가 쉬워졌습니다. 마지막 SQL Server 프로젝트에서 다음 스키마 유형이있었습니다. LT-조회 테이블

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

큰 모듈의 경우 더 많은 스키마로 분리했습니다. 예를 들어 개인 모듈은 5 개 이상의 모듈로 구성됩니다.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

또한 다른 활동 TEMP, MAINTANENCE와 같은 스키마도 포함했습니다. 관리 스튜디오에서 스키마 이름을 사용하여 필터링 할 수 있습니다. MODULE1을 담당하는 개발자는 이름에 따라 필터링하며 거의 항상이 테이블 만 사용합니다. 따라서 개발자, dbas, 신규 이민자 모두 데이터베이스 테이블을 쉽게 이해할 수 있습니다.

모범 사례는 SQL Server의 경우 오라클과 다를 수 있지만 내 경험은 스키마가 적을수록 좋습니다.
특별한 권한이 있고 유지 보수를 수행하는 코드가있는 dba / programmer에 대한 스키마를 갖고 싶습니다. 모든 비즈니스 데이터는 하나의 스키마로 이동하여 어디에 있는지 알 수 있습니다. 명명 규칙은 테이블 사용 또는 저장된 코드 사용을 구별하기에 충분합니다.
서로 다른 데이터로 인해 여러 비즈니스 단위가 있고 각각 고유 한 스키마가 거의 겹치지 않는 경우를 볼 수 있습니다. 그렇지 않으면 간단하게 유지하십시오.