SQL Server에서 "WITH SCHEMABINDING"의 단점은 무엇입니까?
어색하게 명명 된 수백 개의 테이블 (CG001T, GH066L 등)이있는 데이터베이스가 있고 "친숙한"이름을 가진 모든 테이블에 대한 뷰가 있습니다 (예를 들어 "CUSTOMERS"뷰는 "SELECT * FROM GG120T"임). . 내 뷰에 "WITH SCHEMABINDING"을 추가하여 뷰를 인덱싱 할 수있는 것과 같은 몇 가지 이점을 가질 수 있습니다. 그 이유는 몇 가지 뷰가 즉석에서 계산하는 데 비용이 많이 드는 열을 계산했기 때문입니다.
이러한 뷰를 SCHEMABINDING하는 데 단점이 있습니까? 단점을 모호하게 암시하지만 자세히 설명하지는 않는 기사를 찾았습니다. 일단 뷰가 스키마 바운드되면 뷰를 먼저 삭제하지 않고는 뷰에 영향을 줄 수있는 어떤 것도 (예 : 열 데이터 유형 또는 데이터 정렬) 변경할 수 없다는 것을 알고 있습니다. 뷰 자체를 인덱싱하는 기능은 스키마 수정을 더 신중하게 계획하는 것의 단점을 훨씬 능가하는 것 같습니다.
전혀. 더 안전합니다. 우리는 어디서나 그것을 사용합니다.
뷰를 먼저 삭제하지 않는 한 테이블을 변경 / 삭제할 수 없습니다.
오, SCHEMABINDING을 사용하는 데 확실히 다운 사이드 가 있습니다. 이는 SCHEMABINDING에서 비롯된 것입니다. 특히 COMPUTED 열과 결합하여 관계를 "잠금" 하고 "사소한 변경"을 거의 불가능하게 만듭니다.
- 테이블을 만듭니다.
- SCHEMABOUND UDF를 만듭니다.
- UDF를 참조하는 COMPUTED PERSISTED 열을 만듭니다.
- 해당 열에 INDEX를 추가하십시오.
- UDF를 업데이트하십시오.
행운을 빕니다!
- UDF는 SCHEMABOUND이므로 삭제하거나 변경할 수 없습니다.
- COLUMN은 INDEX에서 사용되기 때문에 삭제할 수 없습니다.
- COLUMN은 COMPUTED이므로 변경할 수 없습니다.
글쎄요. 정말..!?! 나의 하루는 방금 PITA가되었습니다. (이제 ApexSQL Diff와 같은 도구 는 수정 된 스키마와 함께 제공 될 때 이를 처리 할 수 있지만 여기서 문제는 스키마 를 처음부터 수정할 수도 없다는 것입니다!)
저는 SCHEMABINDING에 반대하지 않습니다. (이 경우 UDF에 필요합니다)하지만 SCHEMABINDING을 "일시적으로 비활성화"할 수있는 방법 (내가 찾을 수있는)이 없다는 점에 반대합니다 .
이러한 테이블이 타사 앱에서 가져온 경우 (테이블 숨기기로 악명이 높음) 이러한 테이블을 변경하려고하면 업그레이드가 실패합니다.
업데이트 / 업그레이드하기 전에 스키마 바인딩없이 뷰를 변경 한 다음 다시 넣으면됩니다. 다른 사람들이 언급했듯이. 계획, 규율 등이 필요합니다.
한 가지 단점은 뷰를 스키마 바인딩하면 다른 스키마 바인딩 뷰만 참조 할 수 있다는 것입니다.
뷰를 스키마 바인드하려고했지만 참조하는 다른 뷰 중 하나가 스키마 바인드되지 않았기 때문에 스키마 바인딩 될 수 없다는 오류 메시지를 받았기 때문에 이것을 알고 있습니다.
이것의 유일한 결과는 새로운 또는 기존 뷰를 참조하도록 스키마 바운드 뷰를 갑자기 업데이트하려는 경우 새 뷰 또는 기존 뷰도 스키마 바인딩해야 할 수 있다는 것입니다. 이 경우 뷰를 업데이트 할 수 없으며 데이터베이스 개발자가 스키마 바운드 뷰 작업 방법을 알고 있기를 바랍니다.
또 다른 단점은 모든 것에 스키마 한정 이름을 사용해야한다는 것입니다. 다음과 같은 오류 메시지가 많이 표시됩니다.
스키마 바인딩에 'table'이름이 유효하지 않으므로 뷰 'view'를 스키마 바인딩 할 수 없습니다. 이름은 두 부분으로 된 형식이어야하며 개체는 자신을 참조 할 수 없습니다.
또한 스키마 바인딩을 'switch off'하려면 뷰의 select 문을 재정의해야하는 뷰를 변경합니다. 재정의 할 필요가없는 것은 보조금 뿐이라고 생각합니다. 이것은 뷰를 덮어 쓰는 것이 본질적으로 안전하지 않은 작업처럼 보이기 때문에 나를 많이 실망시킵니다.
null이 아닌 제약 조건을 추가하면 열의 데이터 유형을 덮어 쓰는 것과 비슷합니다.
또한 변경하려는 스키마 바운드 개체에 의존하는 다른 뷰 또는 프로 시저를 재정의해야합니다. 즉, 추가하기 위해 (예 : ) 하나의 열에 대한 null이 아닌 제약.
개인적으로 나는 이것이 실제로 해결책을 나타내지 않는다고 생각하며 데이터베이스 변경 사항이 자동으로 적용되는 적절한 프로세스를 갖는 것이 더 낫기 때문에 데이터베이스를 변경하는 것이 악몽이 아닙니다. 이렇게하면 테이블에 변경 사항을 적용 할 때 프로세스의 일부로 모든 뷰 + 함수를 삭제하고 처음부터 다시 만들 수 있습니다 (어쨌든 생성시 확인 됨).
이것은 나에게 단점처럼 보입니다 (#은 내 것입니다) :
Cannot create index on view "###.dbo.###" because it uses a LEFT, RIGHT, or FULL OUTER join, and no OUTER joins are allowed in indexed views. Consider using an INNER join instead.
LEFT 조인이 필요합니다. 이 SO 질문 은 관련이 있습니다.
tSQLt 단위 테스트 프레임 워크를 사용할 때 문제가 발생하고 FakeTable 메서드를 사용할 때 해결 방법이 필요합니다. 이렇게하면 스키마 바인딩을 사용하여 뷰에 연결된 테이블을 가짜로 만들 수 없습니다.
SQL Svr 2005 이후 언급 된 부정적 요소가이 모범 사례를 능가하는 경우는 거의 없습니다. 이는 끔찍한 테이블 스풀링을 방지합니다. 저에게 가장 큰 단점은 스키마 바운드 sproc, funcs, 뷰가 마스터 DB와 같은 "외부"데이터베이스를 포함 할 수 없다는 것입니다. 따라서 예를 들어 프로덕션 코어가 아니라면 모든 훌륭한 실시간 시스템 항목을 휴지통에 버릴 수 있습니다. 데이터베이스는 마스터 내부에 있습니다. 저에게는 시스템이 없으면 삶을 다룰 수 없습니다. 물론 모든 처리에 스풀없는 성능이 필요한 것은 아니며 더 높은 데이터 클래스 계층에서 빠르고 느린 결과를 동시에 결합 할 수 있습니다.
도구 (ssms 등)가 기본 개체의 스키마 변경 실패를 잘 처리하지 못하는 경우 / 우아하게 실제 혼란을 일으킬 수 있습니다. 그것이 제가 지금 함께 앉아있는 것입니다. 그리고 저는 이것이 프린지 케이스라는 것을 압니다.
참고 URL : https://stackoverflow.com/questions/1659320/downsides-to-with-schemabinding-in-sql-server
'Nice programing' 카테고리의 다른 글
| CVS보다 SVN을 사용하면 어떤 이점이 있습니까? (0) | 2020.12.11 |
|---|---|
| 인터페이스의 하위 클래스가 ToString을 구현하도록 강제 (0) | 2020.12.11 |
| 쿠키에 비밀번호를 저장하는 것이 안전합니까? (0) | 2020.12.11 |
| JavaScript를 동 기적으로 동적으로로드 (0) | 2020.12.11 |
| Qt의 양식 레이아웃 메커니즘 이해 (0) | 2020.12.11 |