I store at tinyint (1) - 0 or 1 . I check:

WHERE is_public='1'

Of course, everything works, but I feel that this is wrong. The question is how to organize it correctly and more beautifully?

  • one
    everything is correct, there is no separate boolean type in the muscle - etki
  • that's all right you do - Denis
  • 2
    Only the number with the string does not need to be compared;) - Dmitriy Simushev
  • @Etki there is a boolean type .... only the sense from it is the same as from tinyint with its 1 and 0 - Alexey Shimansky
  • Of course you can take an int and put in it with the help of bit operations up to 32 signs. The question is for what? You will save 1 megabyte on disk for one feature in one million records. You can still do it automatically, 0 stored as NULL, and 1 as 1. then zero values ​​will not take up space. consumption - 1 bit in the header of the record for the NULL flag, but it is more difficult to choose, is null not always convenient to write - Mike

1 answer 1

These values ​​are often stored in CHAR(1) as 'Y' and 'N'. From the advantages of this approach can be noted visibility. However, there is no savings compared with TINYINT(1) , moreover, if at least one VARCHAR column is used in the table, all CHAR columns are automatically treated as VARCHAR . VARCAHR columns are placed in a separate area and are processed more slowly than TINYINT , secondly one byte will be used to set the size of the VARCHAR value and two will be used instead of one byte. Therefore, TINYINT(1) is the most economical and correct option. It is often used by well-known frameworks, for example, Ruby on Rails. I would not change anything in your place.