Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The best option is 0 and 1 (as numbers - another answer suggests 0 and 1 as <em>CHAR</em> for space-efficiency but that's a bit too twisted for me), using NOT NULL and a check constraint to limit contents to those values. (If you need the column to be nullable, then it's not a boolean you're dealing with but an enumeration with three values...)</p> <p>Advantages of 0/1:</p> <ul> <li>Language independent. 'Y' and 'N' would be fine if everyone used it. But they don't. In France they use 'O' and 'N' (I have seen this with my own eyes). I haven't programmed in Finland to see whether they use 'E' and 'K' there - no doubt they're smarter than that, but you can't be sure.</li> <li>Congruent with practice in widely-used programming languages (C, C++, Perl, Javascript)</li> <li>Plays better with the application layer e.g. Hibernate</li> <li>Leads to more succinct SQL, for example, to find out how many bananas are ready to eat <code>select sum(is_ripe) from bananas</code> instead of <code>select count(*) from bananas where is_ripe = 'Y'</code> or even (yuk) <code>select sum(case is_ripe when 'Y' then 1 else 0) from bananas</code></li> </ul> <p>Advantages of 'Y'/'N':</p> <ul> <li>Takes up less space than 0/1</li> <li>It's what Oracle suggests, so might be what some people are more used to</li> </ul> <p>Another poster suggested 'Y'/null for performance gains. If you've <em>proven</em> that you need the performance, then fair enough, but otherwise avoid since it makes querying less natural (<code>some_column is null</code> instead of <code>some_column = 0</code>) and in a left join you'll conflate falseness with nonexistent records.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload