Loại dữ liệu MySQL nào được sử dụng để lưu trữ các giá trị boolean


1207

Vì MySQL dường như không có bất kỳ loại dữ liệu 'boolean' nào, loại dữ liệu nào bạn 'lạm dụng' để lưu trữ thông tin đúng / sai trong MySQL?

Đặc biệt là trong bối cảnh viết và đọc từ / đến một tập lệnh PHP.

Theo thời gian tôi đã sử dụng và thấy một số cách tiếp cận:

  • Các trường nhỏ, varchar chứa các giá trị 0/1,
  • các trường varchar chứa các chuỗi '0' / '1' hoặc 'true' / 'false'
  • và cuối cùng là enum Các trường chứa hai tùy chọn 'true' / 'false'.

Không có điều nào ở trên có vẻ tối ưu. Tôi có xu hướng thích biến thể tinyint 0/1 hơn, vì chuyển đổi loại tự động trong PHP mang lại cho tôi các giá trị boolean khá đơn giản.

Vậy bạn sử dụng loại dữ liệu nào? Có một loại được thiết kế cho các giá trị boolean mà tôi đã bỏ qua? Bạn có thấy bất kỳ lợi thế / bất lợi bằng cách sử dụng loại này hay loại khác?


217
Bất cứ ai đang đọc các câu trả lời cũ cho câu hỏi này cần phải hiểu rằng MySQL đã thêm một kiểu dữ liệu bit trong phiên bản 5. Sử dụng thông tin đó như bạn có thể. dev.mysql.com/doc/refman/5.0/en/bit-type.html
smp7d


7
đối với phiên bản hiện tại của loại MYSQL Boolean có sẵn- dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html kiểm tra điều này. theo giá trị đó, 0 được coi là sai
DevT

7
bit(1)'sa bit ** để nhập trong Excel. Chuyển sang tinyint(1)làm việc.
Cees Timmerman

8
bây giờ chúng tôi có boolean sau 5 năm
V-SHY

Câu trả lời:


1232

Đối với MySQL 5.0.3 trở lên, bạn có thể sử dụng BIT. Hướng dẫn nói:

Kể từ MySQL 5.0.3, kiểu dữ liệu BIT được sử dụng để lưu trữ các giá trị trường bit. Một loại BIT (M) cho phép lưu trữ các giá trị M-bit. M có thể dao động từ 1 đến 64.

Mặt khác, theo hướng dẫn sử dụng MySQL, bạn có thể sử dụng bool và boolean tại thời điểm bí danh của tinyint (1):

Bool, Boolean: Những loại này là từ đồng nghĩa với TINYINT (1). Giá trị bằng 0 được coi là sai. Các giá trị khác không được coi là đúng.

MySQL cũng nói rằng:

Chúng tôi dự định thực hiện xử lý kiểu boolean đầy đủ, theo SQL tiêu chuẩn, trong phiên bản MySQL trong tương lai.

Tài liệu tham khảo: http://dev.mysql.com/doc/refman/5.5/en/numeric-type-overview.html


11
Vâng, tôi sẽ chọn cái này hoặc, cho CHAR (1) và lưu trữ 'Y' / 'N' hoặc 'T' / 'F', v.v. tùy thuộc vào ngữ cảnh. Ưu điểm của việc sử dụng một loại số nguyên nhỏ là bạn có được tính di động tối đa trên RDBMS-es
Roland Bouman

36
Đi tìm char, trong PHP ít nhất, sẽ dẫn đến nhiều mã hơn vì !$booleansẽ không bao giờ đánh giá đúng mà không cần xử lý thêm.
Fuzz nhẹ

10
@Pecerier Không có gì bạn không thể tự google, nhưng ok, tôi sẽ cắn. Trước hết, hãy xem data0type.h. Xin lưu ý rằng innodb không xác định loại BIT ở đó. Nếu nó xử lý các trường BIT theo cách bạn mô tả, chắc chắn chúng tôi sẽ tìm thấy một số gợi ý về sự tồn tại của nó ở đó. Thứ hai, đọc mysqlperformanceblog.com/2008/04/23/ . Và đừng ngần ngại khai sáng cho chúng tôi những khách hàng MySQL tuyệt vời nào trong "marktetplace" chơi tốt với các trường BIT. Họ sẽ có ích cho bất cứ ai bỏ lỡ bài viết đó không có nghi ngờ.
Roland Bouman

9
Khi tôi thực hiện chọn từ các trường bit máy khách dòng lệnh mysql tiêu chuẩn hiển thị hoàn toàn trống. Vì điều này tôi thích TINYINT (1).
Người dùng

8
@MikePurcell Tôi ghét hỏi nhưng tại sao bạn lại muốn auto_incrementtrên một cột đại diện cho một giá trị boolean?
Chris Hayes

248

BOOLBOOLEANlà từ đồng nghĩa của TINYINT(1). Không false, không có gì khác true. Thêm thông tin ở đây .


7
Không (1)có gì khác hơn là xác định cách hiển thị giá trị, nếu bạn có ý thức về kích thước lưu trữ thì bạn muốn sử dụng BITthay vào đó
JamesHalsall 20/03/2016

35
@JamesHalsall: Trên thực tế, BIT(1)TINYINT(1)cả hai sẽ sử dụng một byte lưu trữ. Cho đến MySQL 5.0.3, BITthực sự là một từ đồng nghĩa với TINYINT. Các phiên bản sau này của MySQL đã thay đổi việc triển khai BIT. Nhưng ngay cả khi thay đổi triển khai, vẫn không có lợi ích "kích thước lưu trữ" cho BITkiểu dữ liệu (ít nhất là với InnoDB và MyISAM; các công cụ lưu trữ khác, ví dụ như NDB có thể có một số tối ưu hóa lưu trữ cho nhiều khai báo cột BIT.) Vấn đề lớn hơn là một số máy khách các thư viện không nhận ra hoặc xử lý một cách thích hợp BITcác cột kiểu dữ liệu được trả về . Một TINYINTcông trình tốt hơn.
spencer7593

5
Hướng dẫn sử dụng MySQL 5.0 nói rõ giá trị boolean là 1 hoặc 0. Cụm từ "bất cứ điều gì khác là true" không đúng.
Walter

7
@Walter: Nó thực sự là loại đúng, lời giải thích có phần thiếu. Tóm lại, trong ngữ cảnh boolean, một biểu thức có thể đánh giá thành NULL, FALSE hoặc TRUE. Trong một câu lệnh MySQL, một biểu thức được đánh giá trong ngữ cảnh boolean trước tiên được đánh giá là số nguyên (giá trị thập phân và dấu phẩy được làm tròn, các chuỗi được chuyển đổi theo cách kỳ quặc thông thường mà MySQL chuyển đổi chuỗi thành số nguyên). Một NULL rõ ràng là NULL (không TRUE hay FALSE). Giá trị số nguyên bằng 0 được xử lý dưới dạng FALSE và mọi giá trị nguyên khác (1, 2, -7, v.v.) ước tính thành TRUE. Để tương thích, chúng tôi bắt chước logic / xử lý boolean TINYINT
spencer7593

4
@Walter: Điều này rất dễ kiểm tra, vd SELECT 'foo' AS bar FROM dual WHERE -7. Biểu thức -7 được ước tính trong ngữ cảnh boolean và truy vấn trả về một hàng. Chúng ta có thể kiểm tra bằng 0 hoặc bất kỳ biểu thức nào ước lượng thành giá trị nguyên 0 và không có hàng nào được trả về. Nếu biểu thức trong mệnh đề WHERE ước tính với bất kỳ giá trị nguyên không null nào khác 0, biểu thức là TRUE. (Tôi tin rằng số thập phân và float giá trị nhận được "làm tròn" để số nguyên, ví dụ như WHERE 1/3đánh giá lại để WHERE 0Chúng tôi nhận được kết quả tương tự với. WHERE 'foo', Bởi vì chuỗi 'foo'cũng đánh giá với giá trị số nguyên 0.
spencer7593

71

Đây là một giải pháp tao nhã mà tôi khá đánh giá cao vì nó sử dụng byte dữ liệu bằng 0:

some_flag CHAR(0) DEFAULT NULL

Để đặt thành đúng, đặt some_flag = ''và đặt thành sai, đặt some_flag = NULL.

Sau đó, để kiểm tra true, kiểm tra if some_flag IS NOT NULLvà để kiểm tra false, kiểm tra if some_flag IS NULL.

(Phương pháp này được mô tả trong "MySQL hiệu suất cao: Tối ưu hóa, sao lưu, sao chép và hơn thế nữa" của Jon Warren Lentz, Baron Schwartz và Arjen Lentz.)


3
lừa lạ mắt! Điều này rất hữu ích nếu làm việc với MySQL <5 và thậm chí có thể nhẹ hơn BIT, tuy nhiên trong nỗ lực tuân thủ quy ước và chi phí tính toán ít hơn một chút (logic so với giá trị chính xác) tôi sẽ nói BIT là cách tốt hơn để đi.
zamnuts

59
Có thể là 'nhanh', nhưng nó làm xáo trộn dữ liệu sao cho bất kỳ nhà phát triển mới nào cũng không biết cột này đại diện cho cái gì.
Richthofen

5
Điều này được sử dụng cùng số lượng byte như BIT (1)
ITS Alaska

25
Chúc may mắn nhận được một ORM để ánh xạ độc đáo này.
Craig Labenz

4
Tôi đồng ý với @Richthofen và cảm thấy khó tưởng tượng ra một tình huống mà tôi sẽ ủng hộ việc sử dụng giải pháp này. Tuy nhiên, nếu nó được sử dụng, thì việc chỉ định như một COMMENTđịnh nghĩa trong cột NULLchỉ ra sai và ''chỉ ra đúng có thể đi một cách rất nhỏ để hỗ trợ sự hiểu biết trong tương lai.
eggyal

34

Nếu bạn sử dụng loại BOOLESE, thì đây là bí danh của TINYINT (1). Điều này là tốt nhất nếu bạn muốn sử dụng SQL được tiêu chuẩn hóa và đừng bận tâm rằng trường có thể chứa giá trị ngoài phạm vi (về cơ bản mọi thứ không phải là 0 sẽ là 'đúng').

ENUM ('Sai', 'Đúng') sẽ cho phép bạn sử dụng các chuỗi trong SQL của mình và MySQL sẽ lưu trữ trường bên trong dưới dạng một số nguyên trong đó 'Sai' = 0 và 'Đúng' = 1 dựa trên thứ tự Enum được chỉ định .

Trong MySQL 5+, bạn có thể sử dụng trường BIT (1) để chỉ ra loại số 1 bit. Tôi không tin rằng điều này thực sự sử dụng ít không gian hơn trong bộ lưu trữ nhưng một lần nữa cho phép bạn giới hạn các giá trị có thể thành 1 hoặc 0.

Tất cả những điều trên sẽ sử dụng cùng một dung lượng lưu trữ, vì vậy tốt nhất là chọn nơi bạn thấy dễ làm việc nhất.


8
Nhận xét của bạn về ENUM là không đúng: hãy thử CAST (yourenumcol AS UNSIGNED) và bạn sẽ nhận thấy Sai sẽ là 1 và True sẽ là 2. Một vấn đề khác với ENUM là quá dễ để chèn '' (chuỗi trống ). Tôi sẽ không khuyến khích sử dụng này.
Roland Bouman

4
Theo kinh nghiệm của tôi, việc sử dụng trường BIT (1) từ mã PHP là một chút rắc rối. TINYINT (1) đã dễ dàng hơn rất nhiều và tạo ra mã dễ đọc hơn.
M-Peror

1
@ M-Peror - "sử dụng trường BIT (1) từ mã PHP là một chút rắc rối" ... không có ý định chơi chữ. :) Nhưng, vâng, tôi đồng ý. Tôi nhớ TINYINT (1) cũng dễ dàng hơn ... chỉ không thể nhớ tại sao. Bất cứ ai khác có suy nghĩ về điều này? BIT (1) có vẻ đẹp hơn trên bề mặt vì bạn có thể giới hạn ở 0 hoặc 1. Tôi nghĩ BIT đôi khi được hiểu là dữ liệu nhị phân (tùy thuộc vào ngôn ngữ lập trình và trình điều khiển / thư viện); trong khi đó, TINYINT được đối xử giống như một con số.
BMiner

2
Tài khoản sử dụng trong một biểu thức (boolean).
M-Peror

34

Câu hỏi này đã được trả lời nhưng tôi đoán tôi sẽ ném vào 0,02 đô la của mình. Mình thường dùng a CHAR(0), đâu '' == true and NULL == false.

Từ tài liệu mysql :

CHAR(0)cũng khá hay khi bạn cần một cột chỉ có thể nhận hai giá trị: Một cột được xác định là CHAR(0) NULLchỉ chiếm một bit và chỉ có thể lấy các giá trị NULL''(chuỗi trống).


16
mm, điều này có vẻ như yêu cầu rắc rối nếu bạn như tôi. Ý tôi là, tùy thuộc vào ngôn ngữ, có thể quá dễ dàng để không phát hiện ra sự khác biệt giữa NULL và '' (ví dụ PHP).
Roland Bouman

3
Về mặt tiết kiệm không gian (số byte được sử dụng để đại diện cho boolean), phương pháp này là một chiến thắng rõ ràng. Điều này tiết kiệm một byte qua TINYINT. Nhược điểm (như một số ý kiến ​​chỉ ra) là một số khách hàng có thể gặp khó khăn trong việc phân biệt giữa NULL và chuỗi rỗng. Ngay cả một số cơ sở dữ liệu quan hệ (ví dụ: Oracle) không phân biệt giữa chuỗi có độ dài bằng không và NULL.
spencer7593

3
Điều này rất thông minh! Tôi đã từng viết mã thông minh, bây giờ tôi tránh nó như bệnh dịch. Bây giờ tôi muốn mã của tôi có ý định rõ ràng, không chỉ hành vi đúng. Lời khuyên của tôi? Chỉ làm điều này nếu bạn muốn nhầm lẫn bất cứ ai phải hỗ trợ mã / cơ sở dữ liệu. Chẳng hạn, trong PHP cả ''nullđều là giá trị giả.
CJ Dennis

1
@CJDennis Nếu bạn đã trừu tượng hóa lớp cơ sở dữ liệu của mình phía sau mẫu kho lưu trữ, bạn không phải lo lắng về sự tối nghĩa của giải pháp này.
prograhammer


17

Bit chỉ có lợi thế so với các tùy chọn byte khác nhau (tinyint, enum, char (1)) nếu bạn có nhiều trường boolean. Trường một bit vẫn chiếm một byte đầy đủ. Hai trường bit phù hợp với cùng một byte. Ba, bốn, năm, sáu, bảy, tám. Sau đó, họ bắt đầu điền vào byte tiếp theo. Cuối cùng, khoản tiết kiệm rất nhỏ, có hàng ngàn tối ưu hóa khác mà bạn nên tập trung vào. Trừ khi bạn đang xử lý một lượng dữ liệu khổng lồ, vài byte đó sẽ không tăng thêm nhiều. Nếu bạn đang sử dụng bit với PHP, bạn cần đánh máy các giá trị vào và ra.


1
+1 cho nhận xét typecasting. Để thêm vào điều này khi làm việc với các ngôn ngữ lập trình, tránh sử dụng các kỹ thuật lập trình lười biếng để ủng hộ tính nhất quán. Sử dụng các toán tử giống hệt nhau thay vì chỉ bằng. Trong trường hợp PHP nếu ($ var == "") sẽ đúng với 0, false, null, không xác định và "". để kiểm tra tất cả các giá trị, tốt nhất nên sử dụng if (true === trống ($ var)) vì nó cũng sẽ tránh được các lỗi không xác định. Bạn cũng nên xác thực loại dữ liệu bạn đang làm việc với if (is_int ($ var) && $ var === 0) hoặc typecast nó để buộc nó trở thành một loại dữ liệu cụ thể (int) $ var cho tác vụ.
fyrye

@Thor điều này có đúng với MySQL ở mức độ tương tự với MSSQL không? Tôi đang chuyển một ứng dụng mới chưa đi vào sản xuất từ ​​MSSQL sang MySQL. Tôi không sử dụng PHP mà là chuyển đổi C # sang Java 8. Vì Java là ngôn ngữ được gõ mạnh, tôi không lo lắng về việc xử lý kiểu ... chỉ tất cả các cờ bit sẽ chuyển từ một byte cho tối đa 8 cờ sang 1 byte mỗi cờ cho TINYINT (1). Bạn có biết tài liệu nào về chủ đề này cho MySQL không?
Zack Jannsen 2/2/2016

1
@Thor Thực hiện một số nghiên cứu sâu hơn thì rõ ràng câu trả lời nên là gì. Thay đổi xảy ra và chúng tôi đã thấy sự cải thiện trong việc xử lý này. Biết ngôn ngữ của bạn trong Lớp ứng dụng / Lớp truy cập dữ liệu và biết hỗ trợ thư viện của bạn. Tôi hiện đang sử dụng Java và BIT (1) là lựa chọn được đề xuất tại thời điểm này cho các thư viện như Hybernate và sử dụng JDBC. Đây là URL [Xem bảng 5.2]: dev.mysql.com/doc/connector-j/en/ Kẻ
Zack Jannsen

12

Cho đến khi MySQL triển khai kiểu dữ liệu bit, nếu quá trình xử lý của bạn thực sự bị ép về không gian và / hoặc thời gian, chẳng hạn như với các giao dịch khối lượng lớn, hãy tạo trường TINYINT được gọi là bit_flags cho tất cả các biến boolean của bạn và che dấu bit boolean bạn muốn trong SQL của bạn truy vấn.

Chẳng hạn, nếu bit ngoài cùng bên trái của bạn đại diện cho trường bool của bạn và 7 bit ngoài cùng bên phải không đại diện cho gì, thì bit_flagstrường của bạn sẽ bằng 128 (nhị phân 10000000). Mặt nạ (ẩn) bảy bit ngoài cùng bên phải (sử dụng toán tử bitwise& ) và dịch chuyển 8 bit 8 khoảng trống sang phải, kết thúc bằng 00000001. Bây giờ, toàn bộ số (trong trường hợp này là 1) là giá trị của bạn.

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

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

Bạn có thể chạy các câu lệnh như thế này khi bạn kiểm tra

SELECT (128 & 128) >> 7;

SELECT (0 & 128) >> 7;

Vân vân.

Vì bạn có 8 bit, nên bạn có khả năng 8 biến boolean từ một byte. Một số lập trình viên trong tương lai sẽ luôn sử dụng bảy bit tiếp theo, vì vậy bạn phải che dấu. Đừng chỉ thay đổi, hoặc bạn sẽ tạo ra địa ngục cho chính mình và những người khác trong tương lai. Hãy chắc chắn rằng MySQL có mặt nạ và dịch chuyển của bạn - điều này sẽ nhanh hơn đáng kể so với ngôn ngữ kịch bản web (PHP, ASP, v.v.) làm điều đó. Ngoài ra, hãy chắc chắn rằng bạn đặt một bình luận trong trường bình luận MySQL cho bit_flagstrường của bạn .

Bạn sẽ thấy các trang web này hữu ích khi thực hiện phương pháp này:


7
Điều này có vẻ giống như một cách khủng khiếp để che giấu ý định cho các lập trình viên tương lai. Chắc chắn có vẻ như rất nhiều rắc rối để lưu 7 byte (giả sử bạn đang sử dụng tất cả 8 bool trong bảng duy nhất đó!)
vâng

@yep không có gì khó hiểu cả! Viết tài liệunhận xét MySQL giải thích từng lĩnh vực trong bảng (như câu trả lời đề cập)! Chiến lược vạch mặt MySQL được đề xuất có vẻ vững chắc và lưu trữ tới 16 trường boolean khác nhau chỉ với một vài cột sẽ tốt hơn là có 16 cột thay thế. Nếu quá khó sử dụng thao tác bit và bạn thích sử dụng ngôn ngữ kịch bản web của mình để nhận từng boolean, chỉ cần lưu trữ dưới dạng VARCHARvà thực hiện quy trình vạch mặt trong mã (bạn cũng không cần giới hạn ở 8 trường) ...
CPHPython

Các BITloại tồn tại. Xem dev.mysql.com/doc/refman/8.0/en/bit-type.html
Dolmen

10

Tôi đã chán ngấy với việc cố gắng để có được các số 0, NULLS và '' chính xác làm tròn một vòng các giá trị PHP, MySql và POST, vì vậy tôi chỉ sử dụng 'Có' và 'Không'.

Điều này hoạt động hoàn hảo và không cần điều trị đặc biệt không rõ ràng và dễ làm.


17
Nếu bạn thực sự muốn lãng phí nhiều không gian này và làm giảm hiệu suất, ít nhất bạn có thể thực hiện CHAR (1) với các tùy chọn Y và N.
ILikeTacos

3
Trong hầu hết các tình huống trong thế giới thực, có một sự khác biệt thực sự giữa 'không' và chỉ thiếu thông tin. Ví dụ: bạn có thể muốn có một hộp kiểm được đánh dấu theo mặc định nếu người dùng chưa thực sự nói 'không'. Chính xác thì bạn nghĩ bạn đang tiết kiệm được bao nhiêu dung lượng và bạn xử lý bao nhiêu lần mỗi khi bạn cần phân biệt giữa sai và NULL - nếu thực sự bạn thậm chí CÓ THỂ phân biệt được? Trong một thế giới của hình ảnh được lưu trữ và video kỹ thuật số, bit hoặc hai tiết kiệm không gian hoàn toàn không liên quan nhưng sự rõ ràng và giảm xử lý là có thật.
Geoff Kendall

8
Câu trả lời này không sai vì nó sẽ hoạt động và nó không tệ như mọi người cho nó tín dụng. Đối với hầu hết các dự án (ví dụ: kích thước bảng <1mil hàng) Sự khác biệt về hiệu suất giữa các giải pháp được cung cấp sẽ không được chấp nhận. Tôi sẽ không phàn nàn nếu các truy vấn của tôi trở lại sau 7 so với 5 mili giây ... Để công bằng mặc dù nếu các bảng của bạn đang phát triển thành các hàng 10mil trở lên thì đây có lẽ không phải là giải pháp ưa thích.
Brad

1
+1 từ tôi để sử dụng kiểu dữ liệu ENUM. Cá nhân tôi thích ký hiệu này: ENUM ('y', 'n'). Nó nhỏ gọn (chỉ dài một byte), trực quan và ưa nhìn như quy ước cấp ứng dụng cho tất cả các cờ boolean. Bạn có thể sử dụng nó trực tiếp với các trường mẫu HTML. ví dụ với PHP: <select name = "sản xuất"> <tùy chọn giá trị = "y" <? = $ sản xuất === 'y'? 'đã chọn = "đã chọn"': ''? >> Có </ tùy chọn> <tùy chọn giá trị = "n" <? = $ sản xuất === 'n'? 'đã chọn = "đã chọn"': ''? >> Không </ tùy chọn> </ select>
Vlado

2
Tôi đã nghĩ đến điều này nhưng tôi phải nói @GeoffKendall là đúng. Trong một tấn các trường hợp không cần hiệu suất tối ưu và bất kỳ phương pháp nào công việc cho bạn là phương pháp phù hợp.
Madmenyo

6

Đề cập đến liên kết này Kiểu dữ liệu Boolean trong Mysql , theo cách sử dụng ứng dụng, nếu người ta chỉ muốn 0 hoặc 1 được lưu trữ, bit (1) là lựa chọn tốt hơn.


6
Đúng là BIT(1)sẽ chỉ cho phép một b'0'hoặc b'1'giá trị được lưu trữ. Vấn đề lớn nhất với BITkiểu dữ liệu là các thư viện máy khách khác nhau có nhiều cách xử lý mạnh mẽ của kiểu dữ liệu. Kiểm tra hành vi trong các công cụ SQL khác nhau (SQLyog, TOAD cho MySQL, SQL Developer), các công cụ "kỹ sư đảo ngược" mô hình cơ sở dữ liệu và các máy khách khác nhau, như JDBC, PHP, Perl DBI và để đo lường tốt, hãy thử nghiệm một vài khung ORM ( Ngủ đông, Mybatis, JPA). Về mặt dễ sử dụng, khả năng tương thích công cụ / khung / hỗ trợ riêng, TINYINT(1)là người chiến thắng rõ ràng.
spencer7593

Đúng. Nó hoàn thành tùy thuộc vào khung được xem xét cho ứng dụng. Ví dụ: khung Phalcon của PHP không xử lý kiểu dữ liệu Bit
Vidz

Đối với hồ sơ, MyBatis hỗ trợ cả BITTINYINT. Tham khảo lớp JdbcType của MyBatis, mybatis.org/mybatis-3/apidocs/reference/org/apache/ibatis/type/ trộm
Lucky

1
@Vidz Tôi cung cấp cho bạn một bản để đề cập đến BIT (1) nhưng cũng sẽ chỉ ra cho các nhà phát triển đọc phần này - Biết ngôn ngữ của bạn sẽ nằm trong Lớp ứng dụng / Lớp truy cập dữ liệu và biết hỗ trợ thư viện của bạn. Tôi hiện đang sử dụng Java và BIT (1) là lựa chọn được đề xuất tại thời điểm này cho các thư viện như Hybernate và sử dụng JDBC. Đây là URL [Xem bảng 5.2]: dev.mysql.com/doc/connector-j/en/ Kẻ
Zack Jannsen

6

Do cả MySQL (8.0.16) và MariaDB (10.2.1) đều triển khai ràng buộc CHECK, nên giờ tôi sẽ sử dụng

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

Bạn sẽ chỉ có thể đến cửa hàng 0, 1hoặc NULL, cũng như giá trị mà có thể được chuyển đổi sang 0hoặc 1không có lỗi như '1', 0x00, b'1'hoặc TRUE/FALSE .

Nếu bạn không muốn cho phép NULL, hãy thêm NOT NULLtùy chọn

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

Lưu ý rằng hầu như không có sự khác biệt nếu bạn sử dụng TINYINT, TINYINT(1)hoặcTINYINT(123) .

Nếu bạn muốn lược đồ của mình tương thích lên trên, bạn cũng có thể sử dụng BOOLhoặcBOOLEAN

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

db <> fiddle demo


Điều gì về enum (0, 1)
santiago arizti

3
@santiagoarizti ENUM(phải là enum('0', '1')- lưu ý: đó là những chuỗi) không phải là một ý tưởng tốt. Có quá nhiều vấn đề do cách nó được lưu trữ bên trong và cách xử lý các giá trị không phải là chuỗi. Ví dụ. 0FALSE không thể được lưu trữ. 1TRUEtrở thành '0'. Và 2trở thành '1'.
Paul Spiegel

Câu trả lời hay nhất ... cho những người sử dụng MySQL 8+
dolmen

2

Sau khi đọc câu trả lời ở đây, tôi quyết định sử dụng bit(1)và vâng, bằng cách nào đó tốt hơn về không gian / thời gian, NHƯNG sau một thời gian tôi đã thay đổi ý định và tôi sẽ không bao giờ sử dụng nó nữa. Nó làm phức tạp sự phát triển của tôi rất nhiều, khi sử dụng các câu lệnh, thư viện đã chuẩn bị, vv (php).

Kể từ đó, tôi luôn sử dụng tinyint(1), có vẻ đủ tốt.


3
Quan tâm để giải thích theo cách nó làm phức tạp sự phát triển của bạn?
Chazy Chaz

@ChazyChaz nó mong đợi đúng / sai thay vì 1/0, không giống như một số dbs khác như SQL Server. Điều này đôi khi có thể dẫn đến những tình huống kỳ lạ khi bạn nghĩ rằng bạn đang đặt nó thành sự thật nhưng nó không thực sự xảy ra.
maembe

0

Bạn có thể sử dụng kiểu dữ liệu BOOL, BOOLESE để lưu trữ các giá trị boolean.

Những loại này là từ đồng nghĩa với TINYINT (1)

Tuy nhiên, kiểu dữ liệu BIT (1) có ý nghĩa hơn để lưu trữ giá trị boolean (đúng [1] hoặc sai [0]) nhưng TINYINT (1) dễ dàng hoạt động hơn khi bạn xuất dữ liệu, truy vấn và do đó trên và để đạt được khả năng tương tác giữa MySQL và các cơ sở dữ liệu khác. Bạn cũng có thể kiểm tra câu trả lời hoặc chủ đề này .

MySQL cũng chuyển đổi các loại dữ liệu BOOL, BOOLESE thành TINYINT (1).

Hơn nữa, đọc tài liệu

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.