Hi, On 5/5/07, Ahmed Mohombe <[EMAIL PROTECTED]> wrote:
The problem I see however is that most big DMSes *don't* use JCR because it's slow when it comes to such big amount of documents (it's nice nice in theory but not in practice).
I'm not sure I understand your point. Just like with JDBC, performance is mostly a question of the implementation not the API. There aren't any inherent performance or scalability bottlenecks in the JCR API, so perhaps you are referring to the Jackrabbit implementation?
My experience is that if a (JCR) solution for mail archive wants to be usable to the potential users (much more than is JCR to CMSes and DMSes) performance should be the first and most important feature.
I don't quite agree that performance is the "first and most important" feature, but it certainly is an important aspect. While there are many things to be done for better Jackrabbit performance (and we're working on that), I already find Jackrabbit quite fast for many typical operations. One important aspect in achieving good performance is how you model your content. The JCR model allows a couple of nice modelling options not available in relational databases, most notably in JCR it is possible to avoid many cases of relational joins. For example JCR allows you to store a parsed list of message recipients as a multivalued property of a message node, whereas the equivalent relational model would require a separate table. I would in fact argue that a JCR solution could easily achieve stellar performance for use cases like "find all messages that contain these keywords and that were sent to or from this domain within this timeframe". BR, Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
