Hallo Alexander,
> An effective content model tries to reduce the number of nodes (XML
> imports tend to create lots of nodes with a single property at the
> leaf) and has a high properties/nodes ratio: something around 10 is
> good (ie. 10 times more properties than nodes). This is especially
> true if you use a bundle persistence manager (which you should ;-)),
> because it reads/writes bundles that consist of a node and all its
> properties (except for larger binary properties that will go into
> the DataStore, if configured).
> Having flat hierarchies ("repository in width") is not efficient,
> since Jackrabbit has a limitation when you have many child nodes (>
> 1000) under one node - it will be quite slow then. In favor of human
> explorability one should avoid that anyway, since it is easier when
> the content is structured, eg. by date (/2008/april/*), so that only a
> few children are visible at each level.Thanks for pointing this out! Is this documented somewhere or just internal developer knowledge? Is it for reasons of the JCR concept / API or due to restrictions of the Jackrabbit implementation? Regards, Florian
smime.p7s
Description: S/MIME Cryptographic Signature
