dbo가 아닌 스키마를 사용하는 시점과 새 데이터베이스를 사용하는 시점에 대한 결정 기준

나는 주로 응용 프로그램 개발자이지만 현재 프로젝트 ( btw ... MS SQL Server 2008 )에 대한 모든 선행 데이터베이스 작업을 수행해야한다는 것을 알게되었습니다 . 첫 번째 결정으로, 나는 별도의 데이터베이스를 사용하여 또는 같은 데이터베이스에서 별도의 스키마를 사용하여 상태를 분할할지 여부를 파악하려고합니다. 나는 SQL 서버 스키마의에 약간의 독서를 한 적이 있으며 (별도의 객체 영역에 자연적인 방법처럼 보인다 내가 좋아하는 ),하지만이 패턴에 비용이 숨겨져있을 수 있는지 확실하지 않습니다.

이 두 가지 접근 방식 중에서 선택할 때 고려해야 할 실제 사항은 무엇입니까? 내가 dbo.mytable유리한 입장을 피하면 건축에 myschema.mytable다른 도전 ( 또는 문제 )이 생길 까요?

참고로 ... 어느 시점에서 이것은 유지 관리 / 지원을 위해 실제 DBA로 전달 되므로 삶을 더 힘들게 만들지 않도록 노력하고 있습니다.

OO 의미에서 스키마를 네임 스페이스 또는 객체 도메인으로 간주하지 않는다고 말하는 것으로 시작하겠습니다. 스키마는 본질적으로 값이 추가 된 권한 컨테이너입니다 (아래 참조).

또한 "별도의 스키마"또는 "별도의 데이터베이스"는 서로 다른 개념입니다. 트랜잭션 및 참조 일관성이 필요한 데이터는 동일한 데이터베이스에 있어야합니다. 하나의 데이터베이스 또는 열을 참조하십시오 ? 자세한 내용은 블로그 기사를 참조하십시오.

해당 데이터베이스에서 오브젝트 구성을 위해 스키마를 사용하거나 사용하지 않을 수 있습니다.

개인적으로 저는 스키마의 팬이며 항상 스키마를 사용하지만 권한 및 논리적 그룹화와 같은 용도로 사용합니다. 이를 위해 일반적인 의견이 유리한 점을 확인할 수있는 이전 질문을 참조하도록하겠습니다.

• 스키마 디자인-모범 사례?
• 테이블과 뷰의 이름을 지정할 때 어떤 표준을 따라야합니까?
• 스키마를 과도하게 사용하거나 올바르게 사용합니까?

별도의 데이터베이스에 대해서는 Aaron의 답변을 참조하십시오 . 그러나 이것은 모두 "트랜잭션 및 참조 적으로 일관성있는"요구 사항에 달려 있습니다.

@gbn에 동의하십시오. 분리를 위해 스키마를 사용하고 분리를 위해 데이터베이스를 사용하여 솔루션을 설계했으며 데이터베이스를 사용하는 것이 훨씬 실용적이라는 것을 알았습니다. 몇 가지 이유 :

1. 앱이 컨텍스트 별 데이터베이스에 연결 한 다음 동일한 쿼리를 실행하면 <schema>모든 개체 참조 앞에 쿼리를 삽입하는 것보다 훨씬 쉽습니다 . 이것은 많은 동적 SQL, 기본 스키마를 가진 많은 다른 응용 프로그램 로그인에 적합합니다 (코드가 스키마 접두어를 사용하지 않고 응용 프로그램 사용자의 기본 스키마에 의존 함을 의미합니다-대규모 계획 캐시 팽창 및 어려운 디버깅으로 이어질 수 있음), 또는 관리 할 많은 저장 프로 시저 (스키마 당 하나가 필요한 경우 간단한 보고서 만 작성하면 코드가 변경됩니다. 이제 각 스키마마다 동일한 코드를 여러 번 변경해야합니다).
2. 데이터베이스별로 분리하면 하나의 모든 포괄적 데이터베이스에서 객체를 추출하지 않고도 사용중인 데이터베이스를 더 빠르고 다른 스토리지 / 인스턴스로 이동할 수 있습니다. 대부분의 사람들은 지금까지 그것에 대해 미리 생각하지 않지만 잠재적 인 규모의 문제입니다. 특히 "인계"하고 서버에서 대부분의 리소스를 필요로하는 하나의 스키마가있는 경우 스키마로 이미 분리되어 있어도 분리하는 것은 매우 번거로운 작업이 될 수 있습니다.
3. 별도의 데이터베이스를 사용하면 각 부서마다 다른 유지 관리 및 백업 일정을 가질 수 있습니다. "국가로 나누기"가 무슨 뜻인지 잘 모르겠지만 고객을 격리한다는 가정하에 데이터 손실, 인덱스 유지 관리 등에 대한 요구 사항이 다르고 허용 오차가 다른 고객이있을 수 있습니다.
4. 법이나 회사 정책에 따라 다른 사람과 데이터를 별도로 유지 해야하는 고객이 생길 수 있습니다 . 이것은 일반적으로 데이터베이스 수준에서 허용되지만 스키마 수준은 일반적으로 충분하지 않습니다. 이러한 고객이 없을 수도 있지만 나중에는 실제로 문제가 될 수 있습니다.