Greg Willits wrote: >>> A collection of related apps sharing 4 databases, over 250 tables, with >>> some of those tables having over 200 fields. It was designed to suit dbm >>> philosophies not OO/ORM philosophies. From a Rails perspective they >>> should be broken down into smaller tables and a boatload of has_one >>> associations defined. >> >> Why? There's nothing remotely non-OO about having 200 fields if that's >> what's needed to define the object. > > While that may be technically true, in this case IMO, there are too many > topics fused into one table just because they don't need to be separated > according to DB normalization. IMO, normalization is a good reason to > split things, but the invesre is not always true (no need for > normalization is not a good reason to keep things together).
But there's no reason to split stuff apart solely to avoid wide tables. > > A car could be defined as just one object with 1000 fields, but it's > probably not a good idea. Why not? I see this fear of wide tables/lots of ivars fairly often, and I'm not convinced that it's really justified. If the data is properly normalized, then it's also probably in decent object form. (Of course, usually a decomposition will emerge by the time you have that many fields. But not always.) > > Composition is a friend here IMO. If there's a reasonable decomposition, yes -- say, if there are subsystems in the car, or if several of the fields are duplicated in another table. But there's no advantage to composition just for composition's sake. > > -- gw Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
