On 2009-11-17 17.08, Jacek Sokulski wrote:
1. ACID - although not quite sure if it is real requirement or just habituation ...
This is fair enough I think. Some of the alternative stores are hard to know how resilient they are.
2. reporting - although can set separate RDBMS for reporting/integration
This could/should be done with the CQRS pattern even if you use RDBMS as your application store. We need to make sure it is easy to do this though.
3. risk management - no much experience within our team with non-relational DB, not sure of maturity of such solutions (e.g. see the problem with RDF indexing); Customer requirements - some customers have requirement to use only one DBMS (usually Oracle), e.g. a couple of years ago we have lost a contract just because we have used a hierarchical DB not relational.
What we could do is allow a RDBMS to be used as "backend" for any EntityStore, i.e. you store in e.g. JDBM, but it is also passed using write-behind to a 1-table RDBMS, for fault tolerance/backup purposes.
What will happen, I think, is that people will start seeing the application database more like a cache, which can forward the changes to others stores, which could include RDBMS (and definitely *should* include one for reporting purposes).
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
