On Oct 14, 2008, at 10:52 AM, Peter Jones wrote:
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 ;)
no i think that's pretty much right on. notice, however, that
properties gives you the 'normal' accessors so
model.a = 42
works regardless if whether properties are child objects or in the
record itself. the are quite a few schemas like this in existence,
including ones that manage the relationships parent/child as a
separate table too and they are quite flexible, powerful, and
successful.
i think the real question is: what are you spending more time doing,
creating data or reading it? with relationships and properties
separated creation is always a snap and, while reading might be
slower, the api is always the same for every object. maybe the real
question is how it would scale. my gut says having an index on all
the keys should mean it scales fairly well, the key is the definition
of 'fairly' ;-)
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
_______________________________________________
Bdrg-members mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/bdrg-members
