Marnen Laibow-Koser wrote: > 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.
That's not my purpose. If it just has to be (lots of fields) then it just has to be, but I would expect that to be rare, and it is not necessary in my current case. The table contains easily distinguishable topics, and the code would be better organized, more readable, more orthogonal, simpler to test, and plain simpler to maintain in smaller pieces along the lines of the topics I see in this table. >> 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. Because the magnitude of such a beast with all that data, and the validations that go with it, and all the business rules that go with it probably ends up creating a monster of pig to maintain (obviously no absolutes being preached). It's not a fear of wide tables. It a simple recognition that more smaller pieces usually yields better code than one big piece -- IF that table can be broken up into logical orthogonal pieces. If it really is 200 fields of raw data with no apparant topical divisions, well, fine that sounds like breaking it up just to break it up. That's not the case in my data. -- 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.
