단일 데이터베이스에서 열 데이터 정렬을 혼합하는 것이 왜 나쁜 것으로 간주됩니까?


11

이 질문을하는 데는 두 가지 이유가 있습니다.

tSQLt
T-SQL 테스트 프레임 워크 tSQLt는 기본 데이터 정렬이 아닌 열이있을 때 "높은 심각도" 문제로 간주합니다 . 테스트 작성자는 다음과 같이 말합니다.

모든 문자열 열에 데이터베이스의 기본 데이터 정렬과 일치하는 데이터 정렬이 있어야한다고 제안하지는 않습니다. 대신, 그것이 다를 때, 그럴만한 이유가 있어야한다고 제안합니다.

그러나 언급 된 바와 같이 실패한 테스트의 심각성은 높은 것으로 간주됩니다.

Octopus Deploy
Octopus Deploy 서버를 구성하는 동안 OctopusServer 인스턴스 초기화 중에 치명적 오류와 함께 설치가 실패합니다. 이 단순히 요구 사항이지만, 이유를 설명하지 않는 오류 메시지와 관련된는에서와 문어 버전 3.8를 포함, 향후 구축을위한 요구 사항이 될 것이라고 주장한다.

부수적으로, RedGate의 CI 도구 패키지 인 DLM Automation Suite 는 불만없이 다양한 데이터 정렬을 사용하여 배포를 지원합니다.

모든 열 데이터 정렬을 데이터베이스 기본값으로 유지하는 권장 사항은 지침이나 모범 사례와 비슷합니다. 일부 사람들에게 왜 그렇게 심각한 오류로 간주됩니까?


SQL Cop 테스트의 tSQLt 구현을 참조하고 있습니다. tSQLt 테스트는 통과 또는 실패로 권장되는 기본값을 제공해야합니다. 사용자는 tSQLt 프레임 워크에서 선택한 SQLCop 스키마의 저장 프로 시저에 지나지 않으므로 SQLCop 테스트를 자체 요구 사항에 맞게 조정해야합니다.
David Atkinson

답변:


19

모든 열 데이터 정렬을 데이터베이스 기본값으로 유지하는 권장 사항은 지침이나 모범 사례와 비슷합니다.

당신은 전적으로 정확합니다.

일부 사람들에게 왜 그렇게 심각한 오류로 간주됩니까?

"당신은 절대 사용 해서는 안된다"는 말을 자주 듣거나 읽는 것과 같은 이유로

  • 커서
  • GOTO 진술
  • SQLCLR
  • WITH (NOLOCK)

일부 기능 / 옵션 / 기술은 다른 기능보다 복잡하며 일반적으로 사용시 문제가 발생할 가능성이 문제가 없을 가능성보다 훨씬 크기 때문에 사용자가 더 많은 지식을 필요로합니다. 따라서 일반 인구에 대한 규칙을 일반화하는 것이 더 쉽습니다. 최대 작성할 때 사실, 직장에서 "코딩 표준"나는 항상하는 규칙해야합니다 결코를CURSOR를 사용하지만 "언제"를 사용하는 방법과 효과적으로 사용하는 방법을 알고 있기 때문에 직접 사용합니다. 그러나 가끔 쿼리를 작성하는 사람들은 그 사실을 알 필요가 없습니다. 이것은 "무엇을하고 있는지 절대 알지 않는 한 레지스트리를 편집하지 마십시오"또는 우리가 (아주 어린) 아이들의 부모로서하는 규칙과 유사합니다. 특정 작업을 수행하는 것이 좋을 때 또는 수행 방법에 대한 복잡성을 극복 할 수 없습니다.

데이터 정렬의 경우, 이것은 매우 복잡하고 혼란스러운 주제이며, 하드 오류 (이 문제는 분명하지만 문제를 쉽게 해결할 수 있기 때문에 문제는 적음)와 "홀수"문제가 발생할 수 있습니다. 사물이 왜 그런 방식으로 행동하는지 설명하기 어려운 행동 (일부 항목이 예상 밖의 필터링되거나 필터링되지 않는 이유 또는 정렬이 예상 밖의 행동하는 이유) 그리고 슬프게도, 대량의 혼란을 야기하는 약간의 잘못된 정보가 떠 다니는 것 같습니다. 실제로 데이터 정렬 및 인코딩 등에 대한 일반적인 지식을 크게 높이고 잘못된 정보와 신화에 대항하기를 희망하지만 아직 릴리스 할 준비가되지 않은 프로젝트를 진행하고 있습니다 (이 작업을 링크로 업데이트 함).

데이터 정렬의 경우 비즈니스 사례에 가장 적합한 것을 사용해야합니다. 테이블이나 데이터베이스에서 데이터 정렬을 혼합하지 않는다는 개념이 기본 방법이지만 시스템 카탈로그 뷰의 다양한 열에 사용 된 데이터 정렬을 보면 다양한 데이터 정렬이 사용되는 것을 알 수 있습니다. 따라서 데이터 정렬이 다를 경우 의도적이어야하지만 본질적으로 아무런 문제가 없다는 질문의 주요 인용에 동의합니다.


질문에서 이것에 관해 (강조 추가) :

Octopus Deploy Server를 구성하는 동안 OctopusServer 인스턴스 초기화 중에 치명적 오류와 함께 설치가 실패합니다. 오류 메시지와 관련된 기사에서는 이것이 왜 요구 사항인지 설명하지 않습니다.

링크 된 문서 페이지를 확인했는데 왜 그것이 요구 사항인지 설명합니다. 아래 해당 문서에서 관련 정보를 복사했습니다.

Octopus 데이터베이스에있는 모든 개체의 데이터 정렬도 변경해야합니다. 그렇지 않으면 Octopus 버전 업그레이드 중에 데이터베이스를 수정할 때 오류가 발생할 수 있습니다. 작성된 새 오브젝트는 업데이트 된 데이터 정렬을 사용하며, 예를 들어 원래 데이터 정렬을 사용하여 이러한 오브젝트와 기존 오브젝트 사이에서 SQL 조인을 수행하려고하면 데이터 정렬 불일치 오류가 발생할 수 있습니다.

Octopus 데이터베이스의 코드는 문자열 열 사이에 JOIN이 있으며 향후 업그레이드에서 문자열 열에 추가 JOIN이있는 새로운 코드가 도입 될 수 있다고 합니다. via CREATE TABLE또는을 통해 새 열에 ALTER TABLE ... ADD데이터베이스의 기본 데이터 정렬이 할당됩니다.COLLATE새 문자열 열에 키워드가 지정되지 않았습니다. 그리고 동일한 데이터 정렬을 갖지 않는 문자열 열 사이의 JOIN은 데이터 정렬 불일치 오류를 생성합니다. 그들은 또한 사용자가 콜 레이션이 대소 문자를 구분하지 않아야한다는 유일한 요구 사항이기 때문에 사용자가 자신의 콜 레이션을 선택할 수있는 것처럼 보입니다 (다른 로케일을 수용 할 수 있음). 코드가 존재하는 데이터베이스의 데이터 정렬이 항상 동일한 것은 보장되지 않으므로 COLLATE키워드를 사용하여 모든 새 문자열 열에서 동일한 데이터 정렬을 강제로 적용 할 수는 없습니다 (기술적으로는 가능하지만 동적이 필요함). SQL은 업데이트 스크립트를 생성 할 때 다루기가 쉽지 않습니다). 그들이 사용할 수 있다면 COLLATE키워드를, 그들은 데이터베이스의 기본 데이터 정렬이 문자열 열과 다른 것을 피하십시오. 이렇게하면 어려운 "콜 레이션 불일치"오류를 피할 수 있지만 해당 문자열 열 중 하나를 포함하는 비교 연산의 가능성과 데이터베이스의 데이터 정렬이 아닌 열의 데이터 정렬을 사용하는 "홀수"동작을 유발하는 문자열 리터럴 또는 변수가 여전히 남아 있습니다. 대조. 물론 이것은 예상되는 동작 일 수 있습니다. 그러나 이것은 타사 응용 프로그램이므로 a) 사용자가 원하는 것 (또는 반대하지 않았 음)과 b) 사용자가 버그를 고려한 것 사이의 50 / 50 기회가 아니라 의도 된 것이어야합니다. 야생 거위 추적 및 / 또는 해당 소프트웨어의 버그에 대한 블로그에서 공급 업체의 지원 시간을 낭비합니다.


이 데이터 정렬에 대한 뉴스가 있습니까?
야로슬라프

10

짧은 문장에서 : COLLATION 은 정렬 및 비교를 정의합니다 .

따라서 데이터 정렬 은 SQL Server가 문자 데이터를 비교하고 정렬하는 데 사용하는 규칙을 결정합니다. 이 규칙은 언어 / 로캘을 인식하며 대소 문자, 악센트, 가나 및 너비에 민감 할 수도 있습니다. 데이터 정렬 접미사는 _CS (대 / 소문자 구분), _CI (대 / 소문자 구분), _AS (대 / 소문자 구분), _AI (대 / 소문자 구분) 및 _KS (카나 구분)와 같은 사전 규칙 (입력) 민감도를 식별합니다. 접미사 _BIN (이진) 및 _BIN2 (이진 코드 포인트)로 식별되는 이진 데이터 정렬은 모든 측면에서 민감합니다.

다른 데이터 정렬은 "데이터 정렬 충돌을 해결할 수 없음"오류를 피하기 위해 해결 방법이 필요하며 알려진 비파괴 표현 으로 인해 성능이 저하 될 수 있습니다 . 다른 데이터 정렬을 처리하는 것은 악몽이 될 수 있으므로 (권리가있을 수 있음) 권장 사항을 선택하는 것이 좋습니다.

더 참조 :


1

많은 것들과 마찬가지로, 이전 버전의 SQL에서는 상당히 심각한 문제가 발생할 수 있습니다. SQL7 / 2000에서이 기사를보십시오

SqlServerCentral 데이터 정렬

지금은 훨씬 더 강력 해졌고, 더 현대적인 시스템에서는 정당화 될 수있는 상황이 있지만,이를 변경하는 데에는 여전히 흥미로운 경고가 있습니다.

더 현대적인 버전에 대한 또 다른 유용한 시리즈가 있습니다. 나는 Dan Guzman에 의해, 나는 정기적으로 여기에 게시물을 믿으므로 그는 곧 파이프 할 수 있습니다 :)

SQL 데이터 정렬 지옥

즉, 호환성, 표준화 및 잠재적 인 성능 저하가 혼합 데이터 정렬을 사용하지 않는 주된 이유입니다.


0

데이터 정렬간에 데이터를 전송하면 nchar (16 비트) 대신 char (8 비트 텍스트) 인 경우 데이터가 변경 될 수 있습니다.

나는이 페이지 https://the.agilesql.club/blogs/Blogs/Ed-Elliott/What-collation-variables-take-on-in-T-SQL 에서 변수가 테이블의 텍스트로 할당 될 때, 현재 데이터베이스의 데이터 정렬로 암시 적으로 변환되거나 처리됩니다. 그러나 다른 데이터베이스로 이동할 때 변수의 텍스트는 어떻게됩니까? 해당 바이트가 다시 필요한 경우 새 데이터 정렬로 변환됩니까?

"라틴 문자"악센트를 제거하기 위해 데이터 정렬 트릭을 선택하고 타사 텍스트가 악센트를 질식 시켰기 때문에 필요한 ASCII 텍스트 만 남았습니다. 텍스트는 ASCII와 현대 그리스어 알파벳 만 포함 된 데이터 정렬에 넣었습니다. Collate SQL_Latin1_General_CP1253_CI_AI. 로마 문자에 악센트를주는 "슬란"! ;-)

그러나 내가 그들을 유지하고 싶었다면 나쁜 소식!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.