This solution has been discussed, but for now the expectation is real-time data.
BTW, thanks for your input on this, but I don't want to hijack this thread for my own particular production issues.
I wanted to propose that both ORM (Hibernate, JDO, iBatis) and straight JDBC can/should be used together when one may be better than the other, instead of "trying to fit a square peg into a round hole".
Don't get me wrong, I would love to use ORM all the time, but sometimes I don't think its appropriate.
/robert
Leon Rosenberg wrote:
Moving the implementation is out of my hands.
JDO for RDBMS is an ORM solution which doesn't necessarily answer the question, why not use both (JDBC and ORM)? I think both solutions have merit and I think that many try to make one solution work for both OLAP and OLTP.
Ok, in this case, how about splitting the databases? Keeping OLTP part as
is, and creating the OLAP part on daily (hourly or whatever) import basis as
a separate DB, where you can create fast indexes, which you can't afford in
the OLTP part. Or do you always need to analyse the data instantly?
We once made it for a project, where the customer wanted to create new
queries for statistical purposes from scratch. Like, today i'd like to know, whether the 50.000 users registered in last month were more
female of male, and how many of male users came from north dakota... We created a table, which was imported every night, and contained all the
information about a user, which was available in different parts of the system. So the customer was able to analyse everything, without
running queries against the live-system.
Regards Leon
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
