SQL Server의 "WITH SCHEMABINDING"의 단점은 무엇입니까?
이름이 어색한 수백 개의 테이블(CG001T, GH066L 등)이 있는 데이터베이스가 있으며, "친근한" 이름을 가진 모든 테이블에 대한 뷰가 있습니다(예: "고객" 보기는 "SELECT * FROM GG120T").뷰에 "WITH SCHEMABINDING"을 추가하여 뷰 인덱싱과 같은 관련된 이점을 얻을 수 있습니다. 소수의 뷰에는 계산 비용이 많이 드는 열이 계산되기 때문입니다.
이러한 견해를 결합하는 스키마에는 단점이 있습니까?저는 막연하게 단점을 암시하면서도 결코 자세히 다루지 않는 기사들을 발견했습니다.뷰가 스키마로 가득 차면 뷰를 먼저 삭제하지 않고는 뷰에 영향을 미칠 수 있는 항목(예: 열 데이터 유형 또는 데이터 정렬)을 변경할 수 없다는 것을 알고 있습니다. 하지만 이는 별도로 해야 합니다.보기 자체를 인덱싱하는 기능은 스키마 수정을 보다 신중하게 계획하는 단점을 훨씬 능가할 것으로 보입니다.
보기를 먼저 삭제하지 않으면 테이블을 변경하거나 삭제할 수 없습니다.
오, 스키마 바인딩을 사용하는 것에는 분명히 단점이 있습니다. 이것들은 사실 스키마 바인딩에서 비롯됩니다. 특히 계산된 열과 "잠금" 관계를 결합하고 일부 "사소한 변경"을 거의 불가능하게 만들 때 그렇습니다.
- 테이블을 만듭니다.
- 스키마 바운드 UDF를 만듭니다.
- UDF를 참조하는 계산된 지속 열을 만듭니다.
- 해당 열 위에 INDEX를 추가합니다.
- UDF 업데이트를 시도합니다.
행운을 빌어요!
- UDF는 SCHEMABound이므로 삭제하거나 변경할 수 없습니다.
- 열이 인덱스에서 사용되고 있으므로 삭제할 수 없습니다.
- 계산된 열이므로 열을 변경할 수 없습니다.
음, 프락.정말로...!나의 하루는 방금 피타가 되었습니다.(이제 ApexSQL Diff와 같은 도구는 수정된 스키마와 함께 제공될 때 이 문제를 처리할 수 있지만, 문제는 처음부터 스키마를 수정할 수 없다는 것입니다!)
저는 SCHEMABINDING에 반대하는 것은 아니지만(이 경우에는 UDF에 필요합니다), SCHEMABINDING을 "일시적으로 비활성화"할 방법이 없는 것에는 반대합니다.
전혀 없습니다.더 안전합니다. 어디서나 사용합니다.
한 가지 단점은 뷰를 스키마 바운드하는 경우 다른 스키마 바운드 뷰만 참조할 수 있다는 것입니다.
뷰를 스키마 바운드하려고 했는데 참조하는 다른 뷰 중 하나가 스키마 바운드가 아니기 때문에 스키마 바운드할 수 없다는 오류 메시지가 표시되었기 때문에 이를 알고 있습니다.
이 경우 스키마 바운드 뷰를 갑자기 업데이트하여 새 뷰 또는 기존 뷰를 참조하려는 경우 해당 새 뷰 또는 기존 뷰도 스키마 바운드해야 할 수 있습니다.이 경우 보기를 업데이트할 수 없으므로 데이터베이스 개발자가 스키마 바운드 보기를 사용하는 방법을 알고 있어야 합니다.
이러한 테이블이 타사 앱에서 가져온 것인 경우(테이블 숨기기로 악명 높음) 이러한 테이블 중 하나를 변경하려고 하면 업그레이드가 실패합니다.
업데이트/업그레이드 전에 스키마 바인딩 없이 보기를 변경한 다음 다시 배치하면 됩니다.다른 사람들이 언급한 것처럼.계획, 규율 등이 필요합니다.
또 다른 단점은 모든 항목에 대해 스키마의 정규화된 이름을 사용해야 한다는 것입니다.다음과 같은 오류 메시지가 많이 표시됩니다.
이름 'table'이 스키마 바인딩에 적합하지 않으므로 뷰 'view'를 스키마 바인딩할 수 없습니다.이름은 두 부분 형식이어야 하며 개체가 자체를 참조할 수 없습니다.
또한 스키마 바인딩을 '끄기'하려면 뷰의 선택 문을 재정의해야 하는 뷰를 변경합니다.저는 당신이 재정립하지 않아도 되는 유일한 것은 보조금이라고 생각합니다.보기를 덮어쓰는 것이 본질적으로 안전하지 않은 작업인 것처럼 보이기 때문에 이로 인해 많은 부담을 느낍니다.
이는 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.
왼쪽 관절이 필요해요이 SO 질문은 관련이 있습니다.
tSQLt Unit Test Framework를 사용하면 문제가 발생하고 FakeTable 방법을 사용할 때 해결 방법이 필요합니다. 이 방법을 사용하면 스키마 바인딩으로 보기에 연결된 테이블을 위조할 수 없습니다.
언급된 부정적인 내용은 SQL Svr 2005 이후의 모범 사례를 거의 능가하지 않습니다.이것은 테이블 스풀링을 방지합니다.저에게 주요한 부정적인 점은 스키마 바인딩된 프로시저, 펑스, 뷰가 마스터 데이터베이스와 같은 "외부" 데이터베이스를 포함할 수 없다는 것입니다. 따라서 프로덕션 코어 데이터베이스가 마스터 내부에 있지 않는 한 모든 실시간 시스템 항목을 휴지통에 버릴 수 있습니다.저는 시스템이 없는 삶을 감당할 수 없습니다.물론 모든 프로세싱이 스풀 없는 성능을 필요로 하는 것은 아니며 더 높은 데이터 클래스 계층에서 빠른 결과와 느린 결과를 동시에 결합할 수 있습니다.
도구(sms 등)가 기본 개체의 스키마 변경 실패를 제대로 처리하지 못하면 실제 혼란이 발생할 수 있습니다.그게 제가 지금 앉아 있는 이유이고, 저는 이것이 프린지 사건이라는 것을 알고 있습니다.
언급URL : https://stackoverflow.com/questions/1659320/downsides-to-with-schemabinding-in-sql-server
'programing' 카테고리의 다른 글
| 그룹 수를 사용하여 $group 결과를 얻는 중 (0) | 2023.07.02 |
|---|---|
| 비트 병합 충돌을 해결하기 위해 vimdiff를 어떻게 사용합니까? (0) | 2023.07.02 |
| PHP에서 MySQL 데이터베이스 찾기/바꾸기 스크립트 작성 (0) | 2023.07.02 |
| SqlServer: 사용자 로그인 실패 (0) | 2023.07.02 |
| Vue.js / Vuex + axios가 여러 PUT 요청을 전송함 (0) | 2023.07.02 |