SQL Server 스키마는 무엇입니까?

SQL 데이터베이스, 특히 SQL Server를 사용하는 초보자는 아닙니다. 그러나 나는 주로 SQL 2000 전문가였으며 2005 년에는 항상 스키마에 혼란스러워했습니다. 예, 스키마의 기본 정의를 알고 있지만 일반적인 SQL Server 배포에서 실제로 사용되는 것은 무엇입니까?

나는 항상 기본 스키마를 사용했습니다. 왜 특수 스키마를 만들고 싶습니까? 내장 스키마를 할당해야하는 이유는 무엇입니까?

편집 : 분명히하기 위해 스키마의 이점을 찾고 있다고 생각합니다. 보안 체계로만 사용하려는 경우 데이터베이스 역할이 이미 해당 역할을 채우는 것처럼 보입니다. 그리고 네임 스페이스 지정자로 사용하면 소유권 (dbo 대 사용자 등)으로 수행 할 수있는 것으로 보입니다.

내가 얻는 것은, 소유자와 역할로 할 수 없었던 스키마는 무엇입니까? 그들의 특정 혜택은 무엇입니까?

스키마는 테이블, 프로 시저, 뷰를 논리적으로 그룹화합니다. employee스키마 등 의 모든 직원 관련 개체

또한 하나의 스키마에만 권한을 부여 할 수 있으므로 사용자는 액세스 권한이있는 스키마 만 볼 수 있습니다.

C # 코드의 네임 스페이스와 같습니다.

또한 플러그인 데이터에 대해 일종의 명명 충돌 방지 기능을 제공 할 수 있습니다. 예를 들어 SQL Server 2008의 새로운 변경 데이터 캡처 기능은 사용하는 테이블을 별도의 cdc 스키마에 넣습니다. 이런 식으로, 그들은 CDC 테이블과 데이터베이스에서 사용되는 실제 테이블 사이의 이름 충돌에 대해 걱정할 필요가 없으며, 그 문제 때문에 의도적으로 실제 테이블의 이름을 숨길 수 있습니다.

나는 그것이 오래된 스레드라는 것을 알고 있지만 스키마를 직접 살펴보고 다음이 스키마 사용에 대한 또 다른 좋은 후보가 될 수 있다고 생각합니다.

데이터웨어 하우스에서는 다른 소스에서 가져온 데이터를 사용하여 각 소스마다 다른 스키마를 사용한 다음 스키마를 기반으로 액세스를 제어 할 수 있습니다. 또한 다른 포스터가 위에서 대답 한 것처럼 다양한 소스 간의 이름 충돌이 발생하지 않도록합니다.

스키마를 개별적으로 유지하면 지정된 스키마를 새 DB 서버에 배포하여 애플리케이션을 확장 할 수 있습니다. (이것은 고유 한 기능을 갖기에 충분히 큰 응용 프로그램이나 시스템이 있다고 가정합니다).

예를 들어, 로깅을 수행하는 시스템을 고려하십시오. 모든 로깅 테이블과 SP는 [logging] 스키마에 있습니다. 로깅은 시스템의 다른 기능이 로깅 스키마의 오브젝트와 겹치거나 (결합되는) 경우가 거의 없기 때문에 좋은 예입니다.

이 기술을 사용하기위한 힌트-응용 프로그램 / 시스템의 각 스키마마다 다른 연결 문자열이 있습니다. 그런 다음 스키마 요소를 새 서버에 배치하고 확장해야 할 때 연결 문자열을 변경하십시오.

나는 이것에 대해 브렌트에 동의하는 경향이 있습니다 ... 여기 에이 토론을 참조하십시오. http://www.brentozar.com/archive/2010/05/why-use-schemas/

간단히 말해서 ... 스키마는 매우 구체적인 사용 사례를 제외하고는 크게 유용하지 않습니다. 일이 지저분해진다. 도움이 될 경우 사용하지 마십시오. 그리고 K (eep) I (t) S (imple) S (tupid) 규칙을 따르십시오.

스키마에 연결된 사용자의 별칭을 지정해도 이점이 없습니다. 여기에 이유가 있습니다 ....

대부분의 사람들은 처음에 역할을 통해 사용자 계정을 데이터베이스에 연결합니다. 사용자를 sysadmin 또는 데이터베이스 역할 db_owner에 어떤 형태로든 할당하면 해당 계정은 "dbo"사용자 계정의 별칭이거나 전체 데이터베이스에 대한 권한. 이러한 상황이 발생하면 기본 스키마 (사용자 계정과 이름이 같은) 이외의 구성표에 자신을 할당하는 방법에 관계없이 해당 dbo 권한은 사용자 및 스키마에서 생성 한 개체에 할당됩니다. 그것은 무의미한 ..... 그리고 단지 네임 스페이스이며 그 객체에 대한 진정한 소유권을 혼란스럽게합니다. 당신이 저에게 물어 보면 디자인이 좋지 않습니다.

그들이해야 할 일은 "그룹"을 만들고 스키마와 역할을 버리고 원하는 그룹 조합을 원하는대로 그룹화 할 수 있도록 허용 한 다음 각 계층에서 권한이 상속, 거부 또는 사용자 지정으로 덮어 쓰기되었는지 시스템에 알립니다. 그들. 이것은 훨씬 더 직관적이었고 DBA가 실제 소유자가 해당 객체에있는 사람을 더 잘 제어 할 수있게했습니다. 현재 대부분의 경우 dbo 기본 SQL Server 사용자에게는 사용자가 아닌 이러한 권한이 있습니다.

몇 년 동안 근무한 ORACLE 상점에서 스키마는 다른 프런트 엔드 응용 프로그램에 적용되는 절차 (및 패키지)를 캡슐화하는 데 사용되었습니다. 유스 케이스, 사용자 및 시스템 요구 사항이 상당히 다르기 때문에 각 애플리케이션마다 다른 'API'스키마가 종종 적합했습니다. 예를 들어, 하나의 'API'스키마는 개발 / 구성 애플리케이션이 개발자 만 사용하도록하는 것이 었습니다. 또 다른 'API'스키마는 뷰 및 프로 시저 (검색)를 통해 클라이언트 데이터에 액세스하기위한 것입니다. 또 다른 'API'스키마는 개발 / 구성 및 클라이언트 데이터를 자체 데이터베이스가있는 응용 프로그램과 동기화하는 데 사용 된 코드를 캡슐화했습니다. 이 'API'스키마 중 일부는 다른 'COMMON'을 통해 여전히 공통 절차와 기능을 서로 공유합니다.

스키마를 갖지 않는 것이 아마도 세상의 끝이 아닐 수도 있지만 매우 도움이 될 수 있습니다. 실제로 SQL Server에 패키지가 없기 때문에 실제로 문제가 발생하지만 다른 주제입니다.

스키마는 SQL Server 또는 기타 소프트웨어 도구에 관계없이 많은 새로운 기능과 비슷하다고 생각합니다. 개발 키트에 추가하는 이점이 설계 및 구현의 단순성 상실을 상쇄하는지 여부를 신중하게 평가해야합니다.

스키마가 선택적 네임 스페이스와 거의 같은 것처럼 보입니다. 개체 이름이 충돌하고 권한 세분성이 충분하지 않은 상황이라면 여기 도구가 있습니다. (더 근본적인 수준에서 처리해야하는 디자인 문제가있을 수 있다고 말하고 싶습니다.)

문제가 있다면, 일부 개발자는 일시적인 이익을 위해 일시적으로 사용하기 시작할 것입니다. 일단 들어가면 kudzu가 될 수 있습니다.

SQL Server 2000에서 생성 된 개체는 사용자와 같은 Sam이 Employees와 같은 개체를 만드는 경우와 같이 해당 특정 사용자와 연결되어 있으며 해당 테이블은 Sam.Employees와 같이 나타납니다. 샘이 회사를 떠나거나 다른 사업 영역으로 이동한다면 어떨까요? Sam 사용자를 삭제하면 Sam.Employees 테이블은 어떻게됩니까? 아마도 Sam.Employees에서 dbo.Employess로 소유권을 먼저 변경해야 할 것입니다. 스키마는이 문제를 극복 할 수있는 솔루션을 제공합니다. Sam은 Emp_Schema와 같은 스키마 내에 모든 개체를 만들 수 있습니다. 이제 Emp_Schema 내에 Employees 오브젝트를 작성하면 해당 오브젝트를 Emp_Schema.Employees라고합니다. 사용자 계정 Sam을 삭제해야하더라도 스키마에는 영향을 미치지 않습니다.

개발-각 개발자는 샌드 박스로 자체 스키마를 가져옵니다.

다음은 SQL Server에서 스키마를 사용하는 좋은 구현 예입니다. 우리는 몇 가지 ms 액세스 응용 프로그램을 가지고있었습니다. 이를 ASP.NET 앱 포털로 변환하려고했습니다. 모든 MS-Access 응용 프로그램은 해당 포털의 앱으로 작성됩니다. 모든 MS-Access 응용 프로그램에는 자체 데이터베이스 테이블이 있습니다. 이들 중 일부는 관련이 있으므로 SQL Server의 공통 dbo 스키마에 넣습니다. 나머지는 자체 스키마를 얻습니다. 이렇게하면 ASP.NET 앱 포털에서 어떤 테이블이 App에 속하는지 쉽게 탐색, 시각화 및 유지 관리 할 수 ​​있는지 알고 싶습니다.