What I originally thought that Ara was proposing was a way of doing in-memory quick-mockup stuff with what he wrote, that can arbitrarily and easily be remapped to the real/final DB fields later. So your interface to the model remains constant, even if the underlying DB changes.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Jones Sent: Tuesday, October 14, 2008 10:53 AM To: [email protected] Subject: Re: [Boulder Ruby Group] rfc ara howard <[EMAIL PROTECTED]> writes: > i'd love some feedback from AR users on this pattern > > http://drawohara.com/post/53975615/rails-dynamic-properties-for-activerecord -objects My only concern is how to convert this to a more traditional data model after the prototyping/data modeling phase is complete. It seems fairly nice from a developer point of view, but for performance and reporting, it looks like a headache. I'm currently working on a Rails application that has been in production for a few years and we've decided to create a data mart from this application and a few others that the business is using. Luckily, the database schema that the Rails application is using is pretty sane, so doing raw queries to aggregate data for the data mart's star schema isn't too difficult. However, the more abstract the data relationship becomes, the harder it is to join and aggregate. With this properties system, handmade queries would have to do a lot of casting and compound key joining in order to do aggregation. My gut feeling is that this abstraction comes with a hidden cost. That said, Ara is a lot smarter than I am ;) -- Peter Jones, http://pmade.com pmade inc. Louisville, CO US _______________________________________________ Bdrg-members mailing list [email protected] http://rubyforge.org/mailman/listinfo/bdrg-members _______________________________________________ Bdrg-members mailing list [email protected] http://rubyforge.org/mailman/listinfo/bdrg-members
