Will Merrell wrote: > Marnen Laibow-Koser wrote: >>> You're right that option A is pretty much a bad idea. I can't tell you >>> how much time I have spent refactoring databases that were *guaranteed* >>> never to change. >>> >> >> That shouldn't be a problem. Broadly speaking, it is better to refactor >> a database tomorrow than to overdesign it today. >> > > I'm certainly not in favor of over design, which is why I suggested > something in between. That said, I have rarely seen a case where wide > and shallow is the proper solution.
Likewise. But the OP's problem -- lots of independent attributes -- is one such case. > The OPs problem looks like it needs > some kind of normalization. Nope! The table is already well normalized, I think. If you disagree, please tell me what normalization condition is being violated. > >>> featureable_type ('property', 'unit', or 'room') >> do that unless there's absolutely no alternative. >> > > Could you say a little more about which part of this you find terrible. > I have used techniques like this for some situations, and have seen > others use it also. Oh, it gets used, all right -- by people who either are dealing with unusual situations or don't know how to use a database properly. > If I'm missing something I want to know. If I > misspoke, I want to clean it up. Then just avoid this pattern altogether. See discussion at http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/2ee6d1546a20409e?fwc=1 for more information. 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.