pepe wrote in post #962646: >> > 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.
I wasn't taking it personally. My point was that if I use null in a boolean column, I do not interpret it as equivalent to false. Others might, but that would be a mistake, as you know. [...] >>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. Right. "NULL" is SQL for "I didn't ask". [...] >> > 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. Personal experience is valuable, but you can't always know that this design will be just like the last one. > 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. You know nothing of the sort in most cases. Your actual problems are usually not the ones you anticipated -- after all, if you had anticipated them, you would have anticipated a solution too. > 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. That's a poor trade-off. I know it looks good, but it really isn't. What you're doing is wasting 30-60 minutes for something that you don't need now and may never need. Barring a few special things like I18N, which really is easier to put in at the start, what takes 30-60 minutes to put in now should take 30-60 minutes to put in two years from now when you actually need it. If that's not the case in your codebase, then you're probably not refactoring enough. Best, -- Marnen Laibow-Koser http://www.marnen.org mar...@marnen.org -- Posted via http://www.ruby-forum.com/. -- 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.
