> > Why do I think boolean columns are a little different? You could > > interpret that null is 'similar' to false because it is not true, > > But I'm not. I think SQL has it right: null is neither false nor true.
Out of context. I never said it was and 'you' meant 'anybody'. Sorry if it was misleading. Don't take things so personally. > But that's not even true if we ignore the true 3-valued yes/no/maybe > case. The intent of SQL null is to represent *unknown* data. Imagine > storing data about your friends, including whether they own a car. You > might have a 'has_car' column, which would of course be boolean. > > Now, you may not know (because you haven't asked) whether some of your > friends own a car or not. That is the first thing I ask my friends. Don't you? ;) >So what to put in has_car? You can't put > true. You can't put false. Guess what, you put null! I'd put "I didn't ask" but that wouldn't fit in the boolean column... ;) Very true, though. > > That is > > different IMO than, for example, a date column, which could very > > possibly be conceived to contain either a date or no date at all. > > Could a boolean column be conceived to be null? > > Yes, absolutely. See above. You have certain ability to repeat yourself. > > Certainly, but again, > > not the most likely case in my experience. > > But common enough. Don't pretend it doesn't happen. Not pretending. > > Although an interesting proposition I don't think I would ever use a > > boolean column to store "true/false/maybe sort of things". > > Why not? Fragmented. Because of the explanation I gave. Did you read the whole paragraph? (see below). > > Of course, > > the column could be created to allow it but that, IMO, would defeat > > the purpose of the boolean column. > > No. SQL booleans are three-valued. It makes sense to use that > property. I agree with you in the case of *unkown* data. (From above: you see? this next paragraph explains why. I knew I had written it somewhere!) > > I would rather use a different type > > because, as it happened to me in the past, a 'true/false/maybe' sort > > of scenario can quickly become a 'true/false/maybe/likely/not that > > likely/very likely' sort of scenario and then I would need to change > > my DB and code. > Then change it *at that time*. Sure, and spend who knows how much time changing DB and code if that happens. > You can't know what will happen in the > future, and therefore you can't really design for it. Remember YAGNI. > Don't overdesign. Don't anticipate if anticipation does not give you a > present benefit. YAGNI is a very good principle to follow and I certainly try to adhere to it as much as possible, however it's not the only thing to take into consideration. There is something else I try to use as much as possible, it's called personal experience. There have been times when because of adhering to YAGNI I had to go back and rework A LOT of code. Now I prefer 'overdesigning' a little bit if I see that there is a possibility that not doing so might come back to bite me, even if the only "present benefit" I get is to have peace of mind and know that I won't get bitten by it. I'd rather spend 30 or 60 extra minutes giving a universal solution to a problem or generating related additional functionality that I might see a use for (but not needed right now) than having to go back and spend days reworking something because of those 'saved' 30 or 60 minutes. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
