플래그 배열을 저장하기위한 데이터 유형 (비트 맵 / 비트 배열)

다음 작업을 지원하여 테이블의 각 레코드마다 비트 배열을 저장해야합니다.

• 비트가 설정되어 있는지 테스트하고 비트 설정 (SQL 사용)

• ADO 2.8을 사용하여 값 쿼리 및 설정 (ADO.NET 아님)

• 인덱싱 ( "커버 인덱스"기능을 활용하기 위해)

이 배열에 저장되는 최대 비트 수는 고정되어 있지만 32를 초과 할 수 있습니다 . 즉, 간단한 int 열이 항상 작동하지는 않습니다.

지금까지 내가 본 것 중에서 선택할 수있는 옵션은 다음과 같습니다.

1. 여러 개의 int 열 사용
2. bigint를 사용하십시오 (비트 수가 <= 64 인 한 작동합니다)
3. 이진 사용
4. ?

첫 번째 옵션은 작동하지만 데이터에 액세스하는 코드에서 약간의 리팩토링이 필요합니다. 두 번째 옵션은 일시적인 구제 조치이며, 지금까지 검색에서 ADO가 bigint 와 잘 작동하는지 여부는 확실하지 않습니다 . binary에 대한 경험이 없으며 다른 옵션을 알지 못합니다.

요구 사항에 따라 어떤 데이터 유형을 선택 하시겠습니까?

나는 이것을 위해 단일 필드를 사용하지 않을 만큼 강력하게 옹호 할 수는 없습니다 .

현재 bigint비트 마스크 필드 로 매우 큰 데이터 세트를 유지 관리하고 있으며 약간의 성능 악몽입니다.

단일 비트를 확인하면 괜찮습니다. 둘 이상의 비트를 확인하면 성능이 매우 빠르게 저하됩니다.

비트 마스크 정수의 특성으로 인해 데이터 분배가 매우 불균형하게되고 최적이 아닌 계획을 얻게됩니다.

다중 비트 검사는 모든 행에 대해 실행되는 기능으로 범위 또는 인덱스 스캔을 발생시킵니다. 엉망입니다.

해결 방법은 간단했습니다. 확인할 각 조건에 대한 PK를 저장하는 테이블을 만들었습니다. 처음에는 반 직관적이지만 필요한 공간이 적고 (PK 만 저장), 특히을 사용하는 경우 조회 속도가 매우 빠릅니다 UNIQUE CLUSTERED INDEX.

기본 테이블에 영향을주지 않고 원하는만큼 조건을 추가 할 수 있으며 업데이트는 기본 테이블에 영향을 미치지 않습니다.

모든 룩업 테이블을 개별적으로 인덱싱하고 클러스터 된 키가 기본 테이블에서 동일하고 모든 평가 merge join가 매우 효율적 이기 때문에 인덱싱은 간단합니다 .

저장해야 할 모든 값이 적당한 수의 참 / 거짓 값이면 bit데이터 유형을 사용할 수 있습니다 .

내부적으로 SQL Server는 bit바이트 "청크"로 압축 된 열을 저장 합니다. 따라서 bit테이블 에 최대 8 개의 열이있는 경우 SQL은이를 압축 된 1 바이트로 저장합니다. bit2 바이트의 9-16 열 등.

열 제한에 도달하는 것처럼 들리지 않으므로 매우 간단합니다. 물론 가독성을 높이기 위해 열의 이름을 지정하고 일반적으로 할 수있는 모든 인덱싱 가능성을 얻을 수 있도록 열을 깔끔하게 구분하십시오 (플래그가 매우 선택적인 경우 2008+를 대상으로 지정할 수있는 경우 필터링 된 인덱스가 유용 할 수 있음).

비트 패킹을 직접 수행하면 인덱싱 ( bit마스크의 각 위치를 나타내는 계산 및 인덱싱 된 열이 훨씬 복잡합니다 .하지만 bit직접 사용하는 것보다 나쁩니다 ).