>> 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). A car could be defined as just one object with 1000 fields, but it's probably not a good idea. Composition is a friend here IMO. -- gw -- 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.
