부울 값을 저장하는 데 사용할 MySQL 데이터 유형


1207

MySQL에는 '부울'데이터 유형이없는 것 같습니다. MySQL에 참 / 거짓 정보를 저장하기 위해 어떤 데이터 유형을 '남용'합니까?

특히 PHP 스크립트를 작성하고 PHP 스크립트에서 읽고 쓰는 맥락에서.

시간이 지남에 따라 몇 가지 접근법을 사용하고 보았습니다.

  • 0/1 값을 포함하는 tinyint, varchar 필드
  • 문자열 '0'/ '1'또는 'true'/ 'false'를 포함하는 varchar 필드
  • 마지막으로 두 가지 옵션 'true'/ 'false'를 포함하는 필드를 열거합니다.

위의 어느 것도 최적으로 보이지 않습니다. PHP의 자동 유형 변환은 부울 값을 단순히 제공하기 때문에 tinyint 0/1 변형을 선호합니다.

어떤 데이터 형식을 사용하십니까? 내가 간과 한 부울 값을 위해 설계된 유형이 있습니까? 한 유형 또는 다른 유형을 사용하여 장점 / 단점을 보십니까?


217
이 질문에 대한 이전 답변을 읽는 사람은 MySQL이 버전 5에서 비트 데이터 유형을 추가했음을 이해해야합니다. dev.mysql.com/doc/refman/5.0/en/bit-type.html
— smp7d


7
현재 버전의 MYSQL 부울 유형은 사용 가능 합니다. dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html 확인하십시오. 그 값이 0으로 거짓으로 간주
— DevT

7
bit(1)Excel에서 가져와야합니다. tinyint(1)작동 하도록 전환했습니다 .
— Cees Timmerman

8
지금 우리는 5 년 후에 부울을
— 가졌

답변:


1232

MySQL 5.0.3 이상의 경우을 사용할 수 있습니다 BIT. 매뉴얼은 말합니다 :

MySQL 5.0.3부터 BIT 데이터 유형은 비트 필드 값을 저장하는 데 사용됩니다. BIT (M) 유형은 M 비트 값을 저장할 수있게합니다. M의 범위는 1-64입니다.

그렇지 않으면 MySQL 매뉴얼에 따르면 boint와 boolean을 사용할 수 있습니다. 이는 현재 tinyint (1)의 별칭입니다 .

Bool, Boolean :이 유형은 TINYINT (1)의 동의어입니다 . 0 값은 거짓으로 간주됩니다. 0이 아닌 값은 참으로 간주됩니다.

MySQL은 또한 다음과 같이 말합니다.

향후 MySQL 릴리스에서 표준 SQL에 따라 전체 부울 유형 처리를 구현할 계획입니다.

참조 : http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html


11
예, 상황에 따라 CHAR (1)을 저장하고 'Y'/ 'N'또는 'T'/ 'F'등을 저장합니다. 작은 정수 유형을 사용하면 RDBMS를 통해 최대의 이식성을 얻을 수 있다는 장점이 있습니다.
— Roland Bouman

36
적어도 PHP에서 char을 사용 !$boolean하면 더 이상의 처리없이 제대로 평가되지 않으므로 더 많은 코드가 생성 됩니다.
— Mild Fuzz 2016 년

10
@Pecerier 당신이 구글을 할 수 없었던 것은 없지만, 알겠습니다. 우선 data0type.h를 살펴보십시오. innodb는 기본적으로 BIT 유형을 정의하지 않습니다. 그것이 당신이 묘사하는 방식으로 BIT 필드를 처리한다면, 분명히 거기에 존재하는 힌트를 찾을 것입니다. 둘째, mysqlperformanceblog.com/2008/04/23/…를 읽으 십시오 . "marktetplace"의 놀라운 MySQL 클라이언트가 BIT 필드와 잘 어울리는 것을 망설이지 마십시오. 그들은 의심 할 여지없이 그 기사를 놓친 사람에게 유용 할 것입니다.
— Roland Bouman

9
표준 mysql 명령 줄 클라이언트 비트 필드에서 선택하면 완전히 공백으로 나타납니다. 이 때문에 TINYINT (1)를 선호합니다.
— 사용자

8
@ MikePurcell 묻고 싶지 않지만 auto_increment부울 값을 나타내는 열에서 왜 원 하십니까?
— Chris Hayes

248

BOOL와 BOOLEAN동의어입니다 TINYINT(1). 제로는 false, 다른 것입니다 true. 자세한 내용은 여기를 참조 하십시오 .


7
는 (1)다음 사용하려는 스토리지 크기에 대한 당신이있는 거 의식 경우 값이 표시되는 방법을 결정보다 더 아무것도하지 않는 BIT대신
— JamesHalsall

35
@JamesHalsall : 사실, BIT(1)그리고 TINYINT(1)스토리지를 모두 사용하는 1 바이트 것입니다. MySQL 5.0.3까지는 BIT실제로의 동의어였습니다 TINYINT. 이후 버전의 MySQL에서는 BIT 구현이 변경되었습니다. 그러나 구현 변경으로도 BIT데이터 유형에 대한 "스토리지 크기"이점은 없습니다 (적어도 InnoDB 및 MyISAM에서는 NDB와 같은 다른 스토리지 엔진은 여러 BIT 열 선언에 대해 일부 스토리지 최적화가있을 수 있음). 라이브러리는 반환 된 BIT데이터 유형 열을 인식하거나 적절하게 처리하지 않습니다 . A TINYINT가 더 잘 작동합니다.
— spencer7593

5
MySQL 5.0 매뉴얼에는 부울 값이 1 또는 0이라고 명시되어 true있습니다. " 다른 것 " 이라는 문구 는 사실이 아닙니다.
— Walter

7
@ Walter : 실제로는 사실입니다. 설명이 다소 부족합니다. 간단히 말해서, 부울 컨텍스트에서 표현식은 NULL, FALSE 또는 TRUE로 평가 될 수 있습니다. MySQL 문에서 부울 컨텍스트에서 평가 된 표현식은 먼저 정수로 평가됩니다 (10 진수 및 부동 소수점 값은 반올림되고 문자열은 MySQL이 문자열을 정수로 변환하는 일반적인 기발한 방식으로 변환 됨). NULL은 분명히 NULL입니다 (TRUE 또는 FALSE 아님). 0의 정수 값은 FALSE로 처리하고, 임의의 다른 정수 값 (1, 2, -1, 등) TRUE로 평가. 호환성을 위해, 우리는 모방이 논리 / TINYINT 부울 처리
— spencer7593

4
@Walter : 테스트하기 쉽다 SELECT 'foo' AS bar FROM dual WHERE -7. 식 -7은 부울 컨텍스트에서 평가되며 쿼리는 행을 반환합니다. 0 또는 정수 값 0으로 평가되는 표현식으로 테스트 할 수 있으며 행이 리턴되지 않습니다. WHERE 절의 표현식이 0이 아닌 널이 아닌 정수 값으로 평가되는 경우 표현식은 TRUE입니다. (10 진수와 부동 소수점 값은 정수로 반올림된다고 생각 WHERE 1/3합니다 WHERE 0. 예를 들어로 평가합니다 . WHERE 'foo'문자열 'foo'도 정수 값 0으로 평가 되기 때문에 와 같은 결과를 얻습니다.
— spencer7593

71

이것은 제로 데이터 바이트를 사용하기 때문에 매우 감사합니다.

some_flag CHAR(0) DEFAULT NULL

true로 설정 some_flag = ''하고 설정하고 false로 설정하려면some_flag = NULL .

그런 다음 true IS NOT NULL를 테스트하려면 some_flag인지 확인하고 false를 테스트하려면 some_flag인지 확인하십시오.IS NULL .

이 방법은 Jon Warren Lentz, Baron Schwartz 및 Arjen Lentz의 "고성능 MySQL : 최적화, 백업, 복제 등"에 설명되어 있습니다.


3
멋진 트릭! 이것은 MySQL <5 및 BIT보다 가벼운 풋 프린트로 작업하는 경우에 도움이되지만, 규칙을 따르고 계산 오버 헤드 (논리 대 정확한 값)를 약간 줄이기 위해 BIT가 더 나은 방법이라고 말합니다.
— zamnuts

59
'빠른'것일 수도 있지만 새로운 개발자가 열의 의미를 알지 못하도록 데이터를 난독 처리합니다.
— Richthofen

5
이것은 BIT (1)
— ITS

25
ORM이 이것에 잘 매핑되도록하는 것이 행운입니다.
— Craig Labenz

4
@Richthofen에 동의하며이 솔루션을 사용하여 옹호하는 상황을 상상하기가 어렵습니다. 그러나 이것이 사용될 경우, COMMENT열 정의에서 NULLfalse를 ''나타내고 true 를 나타내는 로 지정하면 향후 이해를 돕기 위해 아주 작은 방법으로 갈 수 있습니다.
— eggyal

34

BOOLEAN 유형을 사용하는 경우 이는 TINYINT (1)의 별명입니다. 표준화 된 SQL을 사용하려는 경우이 필드가 범위를 벗어난 값을 포함 할 수 있음을 염두에 두지 않는 것이 가장 좋습니다 (기본적으로 0이 아닌 값은 'true'임).

ENUM ( 'False', 'True')을 사용하면 SQL에서 문자열을 사용할 수 있으며 MySQL은 필드를 열거 형이 지정된 순서에 따라 'False'= 0 및 'True'= 1 인 정수로 내부적으로 저장합니다. .

MySQL 5+에서는 BIT (1) 필드를 사용하여 1 비트 숫자 유형을 나타낼 수 있습니다. 나는 이것이 실제로 스토리지에서 더 적은 공간을 사용한다고 생각하지 않지만 가능한 값을 1 또는 0으로 제한 할 수 있습니다.

위의 모든 것은 거의 같은 양의 스토리지를 사용하므로 작업하기 가장 쉬운 스토리지를 선택하는 것이 가장 좋습니다.


8
ENUM에 관한 당신의 말이 사실이 아닙니다 : CAST (yourenumcol AS UNSIGNED)를 시도하면 False가 1이고, True가 2라는 것을 알게 될 것입니다. ENUM의 또 다른 문제는 ''(빈 문자열 ) 나는 이것을 사용하지 않는 것이 좋습니다.
— Roland Bouman

4
내 경험상 PHP 코드에서 BIT (1) 필드를 사용하는 것은 약간 번거로운 일이었습니다. TINYINT (1)는 훨씬 쉬우면서 읽기 쉬운 코드를 만들었습니다.
— M-Peror

1
@ M-Peror- "PHP 코드에서 BIT (1) 필드를 사용하는 것은 약간 번거로운 일 이었습니다 ." :) 그러나, 동의합니다. TINYINT (1)도 쉬워 진 것을 기억합니다. 이유를 기억할 수 없습니다. 다른 사람이 이것에 대해 생각이 있습니까? BIT (1)은 0 또는 1로 제한 할 수 있기 때문에 표면에서 더 좋게 보입니다. BIT는 때때로 프로그래밍 데이터 및 드라이버 / 라이브러리에 따라 이진 데이터로 해석되었다고 생각합니다. 반면, TINYINT는 숫자처럼 취급되었습니다.
— BMiner

2
@BMiner-haha, 그것은 의도하지 않았으며, 그것을 알지 못했습니다 :) 그러나 실제로, 내가 정확하게 기억한다면 비트 필드는 이진으로 해석되었지만, tinyint는 숫자로 취급하기 쉽고 그 때문에 더 쉽습니다. (부울) 표현식에 사용하십시오.
— M-Peror

34

이 질문에 대한 답변을 받았지만 $ 0.02를 던질 것이라고 생각했습니다. 나는 종종을 사용한다 CHAR(0).'' == true and NULL == false .

에서 mysql을 문서 :

CHAR(0)두 개의 값만 사용할 수있는 열이 필요한 경우에도 매우 좋습니다. CHAR(0) NULL1 비트 만 차지하고 값 NULL과 ''빈 문자열 만 사용할 수 있는 열입니다.


16
음, 이것은 당신이 나처럼 문제를 묻는 것처럼 보입니다. 언어에 따라 NULL과 ''(예를 들어 PHP) 사이의 차이를 발견하기가 너무 쉽다는 것을 의미합니다.
— Roland Bouman

3
공간 절약 (부울을 나타내는 데 사용 된 바이트 수) 측면에서이 방법이 확실한 승자입니다. TINYINT보다 바이트를 절약합니다. 단점은 (일부 의견에서 지적했듯이) 일부 클라이언트는 NULL과 빈 문자열을 구별하는 데 어려움이있을 수 있습니다. 일부 관계형 데이터베이스 (예 : Oracle)도 길이가 0 인 문자열과 NULL을 구분하지 않습니다.
— spencer7593

3
이것은 매우 영리합니다! 나는 영리한 코드를 작성 했었지만 이제는 전염병처럼 피합니다. 이제 코드가 올바른 행동이 아니라 명확한 의도를 갖기를 원합니다. 나의 충고? 코드 / 데이터베이스를 지원해야하는 사람을 혼동하려는 경우에만이 작업을 수행하십시오. 예를 들어, PHP 모두 ''와 nullfalsy 값입니다.
— CJ 데니스

1
@CJDennis 리포지토리 패턴 뒤에 데이터베이스 계층을 추상화 한 경우이 솔루션의 모호성에 대해 걱정할 필요가 없습니다.
— prograhammer


17

부울 필드가 많은 경우 비트는 다양한 바이트 옵션 (tinyint, enum, char (1))보다 유리합니다. 한 비트 필드는 여전히 전체 바이트를 차지합니다. 두 비트 필드는 같은 바이트에 맞습니다. 셋, 넷, 다섯, 여섯, 일곱, 여덟. 그 후 그들은 다음 바이트를 채우기 시작합니다. 궁극적으로 절감액은 매우 적으므로 집중해야 할 수천 가지 최적화가 있습니다. 엄청난 양의 데이터를 다루지 않는 한, 몇 바이트는 더 이상 추가되지 않습니다. PHP에서 비트를 사용하는 경우 들어오고 나가는 값을 타입 캐스트해야합니다.


1
타입 캐스팅 주석의 경우 +1 프로그래밍 언어로 작업 할 때이를 추가하려면 일관성을 위해 게으른 프로그래밍 기술을 사용하지 마십시오. 동일한 연산자 대신 동일한 연산자를 사용하십시오. PHP의 경우 if ($ var == "")는 0, false, null, undefined 및 ""에 대해 true입니다. 모든 값을 테스트하려면 정의되지 않은 오류도 피할 수 있으므로 if (true === empty ($ var))를 사용하는 것이 가장 좋습니다. 또한 if (is_int ($ var) && $ var === 0)로 작업중인 데이터 유형의 유효성을 검사하거나 태스크에 대해 특정 데이터 유형 (int) $ var가되도록 유형 캐스트해야합니다.
— fyrye

@Thor는 이것이 MSSQL의 경우와 같은 정도입니까? 아직 프로덕션에 들어 가지 않은 새 응용 프로그램을 MSSQL에서 MySQL로 마이그레이션하고 있습니다. PHP를 사용하지 않고 C #을 Java 8로 변환하고 있습니다. Java는 강력한 형식의 언어이므로 유형 처리에 대해 걱정하지 않습니다 ... 1 바이트에서 최대 8 플래그까지 1 비트에서 이동할 수있는 모든 비트 플래그 TINYINT (1)가 주어진 각 플래그 1 바이트. MySQL에 대한이 주제에 대한 문서를 알고 있습니까?
— 잭 얀센

1
@Thor 좀 더 심층적 인 연구를 수행하면 답이 무엇인지 분명합니다. 변경 사항이 발생하여이 처리 방식이 개선되었습니다. 응용 프로그램 계층 / 데이터 액세스 계층에있을 언어를 알고 라이브러리 지원을 알고 있습니다. 현재 Java를 사용하고 있으며 현재 Hybernate와 같은 라이브러리 및 JDBC 사용에 BIT (1)을 권장합니다. 여기에 URL [참조 표 5.2]입니다 : dev.mysql.com/doc/connector-j/en/...
— 잭 Jannsen

12

MySQL이 비트 데이터 유형을 구현할 때까지 대량의 트랜잭션과 같이 공간 및 / 또는 시간에 대한 처리가 진정으로 bit_flags필요한 경우 모든 부울 변수에 대한 TINYINT 필드를 작성하고 SQL에서 원하는 부울 비트를 마스킹하고 이동하십시오. 질문.

예를 들어, 가장 왼쪽 비트가 bool 필드를 나타내고 가장 오른쪽 7 비트가 아무 것도 나타내지 않으면 bit_flags필드는 128 (2 진 10000000)입니다. 비트 연산자를 사용하여 가장 오른쪽에있는 7 개의 비트를 마스킹 (숨기기)하고 &00000001로 끝나는 8 번째 비트 7 공백을 오른쪽으로 이동합니다. 이제 전체 숫자 (이 경우 1)가 값입니다.

SELECT (t.bit_flags & 128) >> 7 AS myBool FROM myTable t;

if bit_flags = 128 ==> 1 (true)
if bit_flags = 0 ==> 0 (false)

테스트 할 때 이와 같은 명령문을 실행할 수 있습니다

SELECT (128 & 128) >> 7;

SELECT (0 & 128) >> 7;

기타

8 비트가 있으므로 1 바이트에서 잠재적으로 8 개의 부울 변수가 있습니다. 미래의 일부 프로그래머는 다음 7 비트를 항상 사용하므로 마스크 해야합니다 . 교대하지 마십시오. 그렇지 않으면 미래에 자신과 다른 사람들을 위해 지옥을 만들 것입니다. MySQL에서 마스킹 및 이동을 수행하도록하십시오. 이는 웹 스크립팅 언어 (PHP, ASP 등)보다 훨씬 빠릅니다. 또한 해당 필드의 MySQL 주석 필드에 주석을 배치해야 bit_flags합니다.

이 방법을 구현할 때 다음 사이트가 유용합니다.


7
이것은 미래의 프로그래머에게 의도를 혼란스럽게 만드는 무서운 방법처럼 보입니다. 물론 7 바이트를 절약하기에는 많은 문제가있는 것 같습니다 (단일 테이블에서 8 개의 부울을 모두 사용한다고 가정합니다!)
— yep

@yep 난독 화가 전혀 없습니다! 쓰기 문서 와 MySQL의 의견 테이블의 각 필드 설명 (대답은 언급으로)! 제안 된 MySQL 마스킹 해제 전략은 견고 해 보이며 , 단지 몇 개의 열로 최대 16 개의 서로 다른 부울 필드를 저장하는 것이 16 개를 갖는 것보다 낫습니다. 비트 조작을 사용하는 것이 너무 혼란스럽고 웹 스크립팅 언어를 사용하여 각 부울을 얻는 것을 선호하는 경우 a로 저장 하고 코드에서 마스킹 해제 절차를 수행하십시오 (8 개의 필드로 제한 할 필요는 없습니다) ...VARCHAR
— CPHPython

BIT유형이 존재합니다. 참조 dev.mysql.com/doc/refman/8.0/en/bit-type.html
— 고인돌

10

나는 0, NULLS를 얻으려고 노력하고 ''PHP, MySql 및 POST 값의 루프를 정확하게 둥글게 만듭니다. 따라서 'Yes'와 'No'를 사용합니다.

이것은 완벽하게 작동하며 명확하지 않고 쉬운 특수 치료가 필요하지 않습니다.


17
이 많은 공간을 낭비하고 성능을 저하 시키려면 최소한 Y 및 N 옵션으로 CHAR (1)을 수행했을 수 있습니다.
— ILikeTacos

3
대부분의 실제 상황에서 '아니오'와 단순한 정보 부재 사이에는 실제 차이가 있습니다. 예를 들어, 사용자가 실제로 '아니요'라고 말하지 않은 경우 기본적으로 확인란을 선택하도록 할 수 있습니다. 정확히 얼마나 많은 공간을 절약하고 있다고 생각하고 거짓과 NULL을 구분해야 할 때마다 얼마나 많은 처리를 수행합니까? 저장된 이미지 및 디지털 비디오의 세계에서, 공간 절약의 비트 또는 두 개는 전혀 관련이 없지만 선명도 및 감소 된 처리는 실제입니다.
— 제프 켄달

8
이 답변은 효과가 있기 때문에 잘못이 아니며 사람들이 신용을주는 것만 큼 나쁘지 않습니다. 대부분의 프로젝트 (예 : 테이블 크기 <1mil 행)의 경우 제공된 솔루션 간의 성능 차이는 무시할 수 있습니다. 내 쿼리가 7 대 5 밀리 초로 돌아 오는 경우 불평하지 않을 것입니다 ... 공평하게 말하면 테이블이 10mil 행 이상으로 커지면 이것이 선호되는 솔루션이 아닙니다.
— Brad

1
ENUM 데이터 형식을 사용하여 +1했습니다. 개인적으로이 표기법을 선호합니다 : ENUM ( 'y', 'n'). 크기가 작고 (1 바이트 길이) 직관적이며 모든 부울 플래그에 대한 응용 프로그램 수준 규칙으로보기 좋습니다. HTML 양식 필드와 함께 직접 사용할 수 있습니다. 예를 들어 PHP : <select name = "production"> <option value = "y"<? = $ production === 'y'? 'selected = "selected"': ''? >> 예 </ option> <option value = "n"<? = $ production === 'n'? 'selected = "selected"': ''? >> 아니요 </ option> </ select>
— Vlado

2
Lol이 내 눈을 사로 잡았지만 @GeoffKendall이 옳다고 말해야합니다. 많은 경우 최적의 성능이 필요하지 않으며 어떤 방법을 사용하든 올바른 방법입니다.
— Madmenyo

6

Mysql 에서이 링크 부울 데이터 유형을 참조 하면 응용 프로그램 사용에 따라 0 또는 1 만 저장하려면 bit (1)이 더 좋습니다.


6
BIT(1)a b'0'또는 b'1'값만 저장할 수 있다는 것은 사실입니다 . BIT데이터 유형 의 가장 큰 문제 는 다양한 클라이언트 라이브러리가 데이터 유형을 다양하게 처리한다는 것입니다. 다양한 SQL 도구 (SQLyog, TOAD for MySQL, SQL Developer), 데이터베이스 모델을 "역 엔지니어링"하는 도구 및 JDBC, PHP, Perl DBI와 같은 다양한 클라이언트의 동작을 확인하고 몇 가지 ORM 프레임 워크 ( 최대 절전 모드, Mybatis, JPA). 사용 편의성 측면에서 도구 / 프레임 워크 호환성 / 네이티브 지원 TINYINT(1)이 확실한 승자입니다.
— spencer7593

예. 완료는 앱에 고려되는 프레임 워크에 따라 다릅니다. 예를 들어, PHP의 Phalcon 프레임 워크는 비트 데이터 유형을 처리하지 않습니다
— Vidz

기록을 위해, MyBatis로 모두 지원 BIT하고 TINYINT. , MyBatis로의 JdbcType 클래스를 참조하십시오 mybatis.org/mybatis-3/apidocs/reference/org/apache/ibatis/type/...을
— 럭키

1
@Vidz 나는 BIT (1)에 대한 언급을 하나 더 주었을뿐 아니라 이것을 읽는 개발자들을 지적 할 것이다.-응용 계층 / 데이터 액세스 계층에있을 언어를 알고 라이브러리 지원을 알고있다. 현재 Java를 사용하고 있으며 현재 Hybernate와 같은 라이브러리 및 JDBC 사용에 BIT (1)을 권장합니다. 여기에 URL [참조 표 5.2]입니다 : dev.mysql.com/doc/connector-j/en/...
— 잭 Jannsen

6

MySQL (8.0.16)과 MariaDB (10.2.1) 모두 CHECK 제약 조건을 구현 했으므로 이제는

bool_val TINYINT CHECK(bool_val IN(0,1))

당신은 가게에 수 0, 1또는 NULL으로 변환 할 수있는 값뿐만 아니라, 0또는 1오류와 같은없이 '1', 0x00, b'1'또는 TRUE/FALSE .

NULL을 허용하지 않으려면 NOT NULL옵션을 추가하십시오.

bool_val TINYINT NOT NULL CHECK(bool_val IN(0,1))

을 사용하면 사실상 차이가 없습니다 TINYINT. TINYINT(1)또는TINYINT(123) .

스키마가 상위 버전과 호환되도록하려면 BOOL또는BOOLEAN

bool_val BOOL CHECK(bool_val IN(TRUE,FALSE))

db <> 바이올린 데모


enum (0, 1)은
— 어떻습니까

3
@santiagoarizti ENUM( enum('0', '1')주의 해야합니다 : 문자열입니다)는 좋은 생각이 아닙니다. 내부 저장 방법 및 문자열이 아닌 값이 처리되는 방식으로 인해 너무 많은 문제 가 있습니다 . 예 : 0및 FALSE 저장할 수 없습니다. 1그리고 TRUE이 될 '0'. 그리고 2됩니다 '1'.
— Paul Spiegel

가장 좋은 대답은 ... MySQL 8 이상을 사용하는 사람들을 위해
— dolmen

2

여기에서 대답을 읽은 후 사용하기로 결정했습니다. bit(1)그렇습니다. 시간 / 시간이 더 나아졌지 만 잠시 후에 마음이 바뀌었고 다시는 사용하지 않을 것입니다. 준비된 문장, 라이브러리 등 (php)을 사용할 때 개발이 많이 복잡해졌습니다.

그 이후로 나는 항상을 사용 tinyint(1)하고 충분히 좋아 보인다.


3
어떤 방식으로 개발을 복잡하게 설명 할 수 있습니까?
— Chazy Chaz

@ChazyChaz SQL Server와 같은 다른 데이터베이스와 달리 1/0 대신 true / false를 기대합니다. 이것은 때때로 당신이 그것을 true로 설정한다고 생각하지만 실제로는 일어나지 않는 이상한 상황으로 이어질 수 있습니다.
— maembe

0

부울 값을 저장하기 위해 BOOL, BOOLEAN 데이터 유형을 사용할 수 있습니다.

이 유형은 TINYINT (1)의 동의어입니다.

그러나 BIT (1) 데이터 형식은 부울 값 (true [1] 또는 false [0])을 저장하는 것이 더 적합하지만 데이터를 출력하거나 쿼리 할 때 TINYINT (1)을 사용하는 것이 더 쉽습니다. MySQL과 다른 데이터베이스 간의 상호 운용성을 달성합니다. 이 답변 또는 스레드를 확인할 수도 있습니다 .

또한 MySQL은 BOOL, BOOLEAN 데이터 형식을 TINYINT (1)로 변환합니다.

또한 설명서를 읽으십시오

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