Originally posted by: Yspadadden
Yes, I do. I am less concerned about storage requirements as I am concerned about data type consistency. If I want to represent a boolean a bit is exactly what I need. A tiny int can have a lot of other values, which are invalid as a boolean. It can have any number in (0, 255). This would mean, I then had to create check constraints or, on a mysql db, triggers, to check that the values in the field are only in the range of (0, 1). Alternatively I could argue, that anything other than 0 is true, or I could argue that anything other than 1 is false. Both are valid and make sense depending on the circumstances you use it. If multiple developers work on a project one might choose one logic and the other might choose another logic. (This is a fact of live)
Additionally, any tools (I have) used to auto map between the db and an object structure will automatically interpret a bit as a boolean. Where a tiny int will result in a byte or some other integer type.
Now for the main point: Liquibase still makes a mistake and that is what I wanted to communicate with my post. So type discussions (although sometimes interesting) are beside the point.
You’re right about liquibase in your main point, i was just interested in “type discussion” topic :), i’m just a user here, not a developer.
I personally don’t like this type because you have to always remember about its “binary” nature. For example this query
INSERT INTO bit_table SET id = '0'
will insert 1 instead of 0 in BIT(1) field because ord('0') is 48 which is much bigger than 1. For restriction of possible values I'd use ENUM in your case, so you can define your values as FALSE, TRUE or maybe even in your domain logic terms as ENABLED, DISABLED and etc.