dbo 스키마를 피해야합니까?

dbo 스키마와 관련하여 :

• 데이터베이스 개체를 만들 때 dbo 스키마를 사용하지 않는 것이 가장 좋은 방법입니까?
• dbo 스키마를 피해야하는 이유는 무엇입니까?
• 어떤 데이터베이스 사용자가 dbo 스키마를 소유해야합니까?

데이터베이스를 사용하는 다른 사용자가있을 때 스키마를 사용하여 액세스를 제한 할 수 있기 때문에 좋은 습관 일 수 있습니다. 예를 들어 데이터베이스에는 다음 표가 있습니다.

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

HR 디렉터로서 나는 HR스키마의 모든 것에 액세스 할 수 있으며, IT디렉터 로서 직원의 사용자 이름과 액세스 레벨을 볼 수 있습니다. Engineering부서는 DBO가 나는 열심히 시간 내 데이터를 분할하고 액세스 역할을 제공하는 것 모든 테이블에 대한 설정 스키마 인 경우 작업 현장 등, 활동이 무엇인지 볼 수 있습니다.

SQL Server의 아이디어는 다른 부서에서 액세스하고 쿼리 할 수있는 제품을 제공하는 것입니다. 실제로는 DBA / DBDev만이 실제로 데이터베이스에 액세스하며 일반적으로 애플리케이션 데이터 만 저장합니다.

또한 가독성과 관리 효율성에 도움이됩니다. 처음에 나는 어떤 테이블이 어떤 데이터를 보유하고 있고 어떻게 데이터가 분리되어 있는지 쉽게 식별 할 수 있습니다.

개인적으로 저는 일반적인 관행으로 스키마를 정의하는 것을 선호합니다. 스키마는 계획을위한 그리스어라는 점을 기억하십시오. 계획된 스키마 구조를 통해 데이터를 계획하고 식별 할 수 있습니다.

실제로 기술적 인 이유가 없기 때문에 이것이 사용자 선호에 달려 있다고 생각합니다. 실제로 간단하게하기 위해 보안 요구 사항이 달리 명시하지 않는 한 항상 dbo를 사용한다고 말합니다. 물론 항상 조직적인 목적으로 만 할 수 있습니다.

dbo는 SQL Server의 기본값이기 때문에 피해야 할 것이지만 설명이 아닙니다. 다른 모든 기본 이름과 마찬가지로, 이미 알려져 있기 때문에 해커의 삶을 훨씬 쉽게 만들 수 있습니다 (스키마 이름을 알아 내려고하는 시점에 있다면 이미 이미 지쳤을 것입니다).

내가 일하는 곳에서는 스키마를 사용하여 데이터베이스를 논리적 섹션으로 나누고 스키마에 권한을 할당합니다.

예를 들어, 데이터베이스가있는 인벤토리 시스템이있을 수 있습니다. 기본 테이블은 inv 스키마에있을 수 있습니다. 데이터베이스로 무엇이든 가져 오면 스테이징 스키마가 가져 오기 프로세스의 일부로 사용됩니다. 사용자가 액세스 할 필요가없는 시스템 저장 프로 시저가 있으면 sp 스키마에 넣습니다.

SQL 2005 이전에는 스키마가 숨겨져 있으므로 모든 것이 dbo 스키마에 포함되었으므로 이전에는 모범 사례가 아니 었습니다. SQL Server 팀은이를 모범 사례로 표시하고 이에 관한 기사를 게시했습니다. SQL Server 모범 사례 – 데이터베이스 개체 스키마 구현

누가 그것을 소유해야하는지에 대한 다른 질문 : dbo 스키마는 dbo 사용자 계정이 소유합니다.