How you store your Boolean values depends very much on the semantics of the field in which the value is stored. It's sometimes reasonable to store Boolean values as character fields containing "T"/"F", "Y"/"N", "IN"/"OUT", "BLACK"/"WHITE", "PINK"/"BLUE", or whatever suits your data. Sometimes you may want to store that Boolean as a NUMBER in Oracle, with allowable values of 1 and 0, or 100 / 0, or 1 / -1, or whatever suits your needs. We often use Booleans to mean any number of different things - which is why Oracle doesn't supply a Boolean type. You should use a data type and values which are appropriate for your application.
As far as the CHAR vs. VARCHAR2 argument I recommend using VARCHAR2 because CHAR doesn't always behave as you (or at least "I" :-) expect. By way of explanation, consider the following block:
DECLARE
PROCEDURE test_string(pinString IN VARCHAR2) IS
strTest VARCHAR2(3) := pinString;
cTest CHAR(3) := pinString;
BEGIN
DBMS_OUTPUT.PUT_LINE('strTest=' || CASE
WHEN strTest IS NULL THEN 'NULL'
ELSE '''' || strTest || ''''
END ||
' cTest=' || CASE
WHEN cTest IS NULL THEN 'NULL'
ELSE '''' || cTest || ''''
END);
END test_string;
BEGIN
test_string('A');
test_string('AB');
test_string('ABC');
test_string('');
test_string(NULL);
END;
When run this outputs:
strTest='A' cTest='A '
strTest='AB' cTest='AB '
strTest='ABC' cTest='ABC'
strTest=NULL cTest=' '
strTest=NULL cTest=NULL
The first three lines and the last line aren't a surprise, but the fourth line is a bit surprising to me. I've always understood that an empty string is equivalent to NULL. However, that fourth and fifth lines of output seem to be contrary to that assumption. In the fourth line we've assigned a zero-length string to the VARCHAR2 input parameter, which was subsequently assigned to both strTest and cTest. In the case of strTest when we test it in the VARCHAR2 test code it's detected as NULL. However, when this zero-length string is assigned to cTest, cTest is padded on the right with spaces until it's a full 3 characters long. This is not surprising when considered in the context of the CHAR data type, but it produces a result I don't expect based on my use of VARCHAR2. It's also interesting because it implies that A) a zero-length VARCHAR2 value is actually stored as a zero-length string and not as a NULL, and B) the "zero-length-string-is-NULL" determination is done at runtime.