Topic: MySQL rows.

I see many TINYINT(1) rows, many of which I assume are either a '0' or '1' value. Why is this? Wouldn't it be better to have an ENUM('0', '1') instead?

http://dev.mysql.com/doc/refman/5.0/en/enum.html

Re: MySQL rows.

Rickard would have to answer this, but I think it's because we're using numbers and enum is a set of strings (which can be confusing when you're storing numbers as strings: you can get tripped up and accidentally use the numerical indexes instead of the string numbers).

3 (edited by guardian34 2007-03-05 23:21)

Re: MySQL rows.

From the same page:

If you store a number into an ENUM column, the number is treated as the index into the possible values, and the value stored is the enumeration member with that index. (However, this does not work with LOAD DATA, which treats all input as strings.) If the numeric value is quoted, it is still interpreted as an index if there is no matching string in the list of enumeration values. For these reasons, it is not advisable to define an ENUM column with enumeration values that look like numbers, because this can easily become confusing. For example, the following column has enumeration members with string values of '0', '1', and '2', but numeric index values of 1, 2, and 3:

numbers ENUM('0','1','2')

If you store 2, it is interpreted as an index value, and becomes '1' (the value with index 2). If you store '2', it matches an enumeration value, so it is stored as '2'. If you store '3', it does not match any enumeration value, so it is treated as an index and becomes '2' (the value with index 3).

Edit: Emphasis added.

Re: MySQL rows.

Exactly: it's too easy to confuse indices with the actual values (plus, the actual values become strings instead of numbers)

Re: MySQL rows.

Ah, I see. I ought to read my citations!