Tinyint 대 Bit?

여기서 종교 전쟁을 시작하고 싶지는 않지만 데이터베이스에서 부울 값을 표현하는 방법에 대해 두 가지 생각이있는 것 같습니다. 어떤 사람들 bit은 적절한 데이터 유형 이라고 말하고 다른 사람들 tinyint은 더 낫다고 주장 합니다.

내가 아는 유일한 차이점은 다음과 같습니다.

• bit: 저장 크기는 1 비트, 가능한 값은 0 또는 1입니다.
• tinyint: 저장 크기는 1 바이트, 가능한 값은 0-255입니다.

부울 값을 표시해야 할 때 어떤 데이터 유형이 더 낫습니까? tinyint1보다 큰 값이 필요한 경우에 대비하여 추가 오버 헤드 가 가치가 있습니까?

테이블에 비트 열을 추가하면 단일 비트가 아닌 각 레코드에서 전체 바이트를 차지합니다. 두 번째 비트 열을 추가하면 동일한 바이트에 저장됩니다. 아홉 번째 비트 열에는 두 번째 바이트의 저장 공간이 필요합니다. 1 비트 열이있는 테이블은 스토리지 이점을 얻지 못합니다.

Tinyint와 bit는 둘 다 작동하도록 만들 수 있으며, 둘 다 성공적으로 사용했으며 강한 선호도가 없습니다.

비트 ... 당신이 "참 / 거짓 / 파일을 찾을 수 없음"클랜에 속하지 않는 한

참조를받지 못한 경우 ...

Linq2SQL의 경우 비트는 참 / 거짓으로 작동하므로 프로그래밍이 더 쉽습니다. 둘 다 장점이 있습니다.

또한 고려해야 할 프로그래밍 유지 관리도 있습니다. 귀하 (또는 중학교 인턴 프로그래머)가 2, 3, 25, 41, 167, 200 등을 사용하면 어떻게됩니까? 어디에 문서화되어 있습니까? 비트는 자체 문서화 되고 매우 보편적입니다.

적절한 경우 비트를 사용합니다. 의미 론적으로 올바른 유형 (의미론 계산!) 외에도 단일 행 (어쨌든 SQL Server에서)에있는 여러 비트 필드 (최대 8 개)를 단일 바이트 저장소로 통합 할 수 있습니다. 8 번째 이후에는 다음 8 번째에 대해 추가 바이트가 필요합니다.

참조 :

• SQL 2000
• SQL 2005
• SQL 2008

MySql 사용자의 경우-MySQL 에서 BIT 열을 사용하면 안되는 이유

이전 StackOverflow 게시물 : MySQL에서 BIT와 TINYINT의 차이점은 무엇입니까?

새로운 "BOOL"열을 추가 할 때 MySQL은 실제로 TINYINT를 사용합니다.

나는 BOOL (일명 TINYINT )을 고수 하고 인생을 계속 진행할 것입니다.

정의상 부울은 두 개의 값만 허용합니다. 이것을 위해 왜 하나 이상의 것이 필요합니까? 3 개 (또는 그 이상) 상태 논리가 필요한 경우 더 큰 데이터 유형을 사용하지만 표준 부울 논리에 대해 비트 필드를 계속 사용합니다.

비트를 사용하면 검사 제약 조건을 사용할 필요가없고 ORM이 자동으로 비트를 nullable 부울 (C #)로 변환 할 수 있기 때문에 한 번 코딩하면 매우 감사합니다.

False를위한 공백 없음

무엇을 선택하든 NULL대신으로 설정할 수 있으며 추가 공간0 을 차지 하지 않습니다 (데이터베이스는 거의 항상 NULL모든 행의 모든 ​​필드에 대한 플래그를 가지고 있기 때문에 여기에 더 많은 정보를 제공합니다 ). 또한 기본값 / 가장 가능성이 높은 값이임을 확인하면 false더 많은 공간을 절약 할 수 있습니다!

진실을위한 약간의 공간

표시 할 값 true에는 필드 유형으로 정의 된 공간이 필요합니다. 를 사용 BIT하면 테이블에 이러한 열이 여러 개있는 경우에만 공간이 절약됩니다. TINYINT이는 8 개 필드 당 1 바이트 를 사용하기 때문입니다 (필드 당 1 바이트를 사용하는 경우 와 비교 ).

TINYINT추가 열 관리에 대해 걱정하지 않고 8 값 비트 마스크 를 사용자 정의 할 수 있다는 장점이 있으며 검색이 이론적으로 더 빠릅니다 (단일 정수 필드 대 여러 비트 필드). 그러나 느린 순서, 멋진 교차 인덱싱 항목 및 필드 이름 부족과 같은 몇 가지 단점이 있습니다. 나에게 가장 큰 손실은 무엇입니까? 데이터베이스는 어떤 비트가 어떤 비트 마스크에서 무엇을했는지 기록하기 위해 외부 문서를 필요로합니다.

어쨌든 TEXT필드를 사용 하여 부울 또는 그 집합을 저장 하려는 유혹을 피하십시오 . 텍스트를 검색하는 것은 서버에서 훨씬 더 많은 작업이며 "on, off, off"와 같은 임의의 이름 지정 체계는 상호 운용성을 손상시킬 수 있습니다.

방금 비트 그룹화 (SQL Server 2k5)를 시도했는데 잘 작동했습니다. 응용 프로그램에 올바른 데이터 유형을 사용하는 것을 좋아합니다. 그것이 참 / 거짓 필드라면 비트는 내가 사용하는 것입니다 ...

이 모든 이론적 토론은 훌륭하지만 실제로는 최소한 MySQL을 사용하고 실제로 SQLServer를 사용하는 경우에는 작업하기가 더 쉽다는 간단한 이유로 부울에 대해 이진이 아닌 데이터를 고수하는 것이 가장 좋습니다. 데이터를 출력하고 쿼리하는 등. MySQL과 SQLServer 간의 상호 운용성을 달성하려는 경우 (즉, 둘간에 데이터를 동기화하려는 경우) 특히 중요합니다. BIT 데이터 유형 처리가 둘에서 다르기 때문입니다. 따라서 실제로 숫자 데이터 유형을 고수하면 번거 로움이 훨씬 적습니다. MySQL이 TINYINT (1)로 저장되는 BOOL 또는 BOOLEAN을 고수하는 것이 좋습니다. MySQL Workbench와 MySQL Administrator가 BIT 데이터 유형을 표시하는 방식조차 좋지 않습니다 (바이너리 데이터에 대한 작은 기호).

위에서 언급 한 것 같지는 않지만 BIT 열 (예 : MIN, MAX, 특히 SUM)을 집계 할 수 없다는 문제가 있습니다. 방금 2008을 사용하여 테스트했지만 문제는 여전히 존재합니다. 이것이 제가 최근에 tinyint를 사용하는 가장 큰 이유입니다. 다른 하나는 tinyint가 확장되는 방식을 좋아한다는 것입니다. "두 값"비트 플래그가 갑자기 더 많은 가능한 값을 필요로 할 때 항상 고통 스럽습니다.

우리는 int "vector"필드로 모든 테이블을 만듭니다. 그런 다음 해당 필드를 어떤 용도로도 할당 할 수있는 32 비트 모음으로 사용합니다. (잠재적으로 상태 집합에 비트 그룹 사용). 잊어 버린 경우 플래그 필드를 계속 추가 할 필요가 없습니다.

@Kevin :group by 비트 필드에서 사용할 수 있다고 생각 합니다 (SQL Server 2005) :

declare @t table (
    descr varchar(10),
    myBit1 bit, 
    myBit2 bit
)
insert into @t values ('test1', 0, 1)
insert into @t values ('test2', 1, 0)
insert into @t values ('test3', 1, 1)
insert into @t values ('test4', 0, 0)

select myBit1, count(myBit1) from @t group by myBit1
select myBit2, count(myBit1) from @t group by myBit2

결과 :

myBit1 
------ -----------
0      2
1      2

myBit2 
------ -----------
0      2
1      2

TinyInt가 선호합니다. 그런 다음 필드에 대해 집계 된 카운트를 수행 할 때 캐스팅 할 필요가 없습니다. 또한 일부 프런트 엔드 언어는 Bit를 다른 언어와 다르게 해석하며 TinyInt를 사용하면 모든 프런트 엔드 언어에 대해 유효성 검사가 보편적으로 수행됩니다.

MySQL을 사용하는 경우 BIT 데이터 유형 ( http://www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/) 을 사용하지 않는 것이 좋습니다 .

나는 'T'또는 'F'와 함께 char (1)을 사용하는 것을 좋아합니다. 예, 다른 값과 함께 남용 될 수 있지만 적어도 비트 또는 이진 값을 사용하기가 더 어려운 보고서 또는 기타 장소에서보기 쉽습니다.