jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naseeruddin Mohammad" <naseer...@gmail.com>
Subject Re: Complex Hierarchy best practices
Date Tue, 20 Feb 2007 01:10:03 GMT

     I got it, after going through your suggestions I got a better
understanding of how things work  w.r.t JCR.

     To convience my self can I actually see the data model created by

Can you tell me exactly which which persistant manager and FileSystem
component should be used, to see the ER diagram of the relational tables?

Thanks for your feedback,

On 2/19/07, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On 2/18/07, Naseeruddin Mohammad <naseer.md@gmail.com> wrote:
> > I have the following hierarchy to take care of, I am not sure that if I
> > blindly use the JCR APIs to create this structure the resulting
> datamodel
> > will be effecient, as my hierarchy is deep as well as wide. Please
> provide
> > your thoughts, feedback and options avilalable for me to address this
> Issue.
> Looks nice on the outset. Some comments inline.
> > -Root Node
> It is generally a good idea to have an application-specific root node,
> like /my:content where my is your namespace prefix, under which you
> file all your content. This helps with backups and queries as you
> don't need to explicitly exclude /jcr:system or any other extra
> content within the root.
> Using your own namespace for that node avoids any collisions with
> other applications you may want to include in the same workspace. Also
> as a general rule (best practice even?), I usually use namespace
> prefixes for nodes and properties whose names are fixed in my
> application and put all user-entered names in the default namespace
> without a prefix.
> > ----Departments (Node)*
> > ------ Department Description Document (Property)
> > ------ Department Motto Description (Property)
> > ------ Department Location (Property)
> Is the Document a full document file like a PDF or just a text field?
> In the former case you should probably store it as an nt:file node.
> The same goes for the other "Document" properties in your model.
> > ------ Events (node)*
> > ------------- Events Name and Description (Property)
> If you're planning to keep a full archive of all events over time,
> then you may want to introduce some sort of an internal hierarchy, for
> example an extra hierarchy level for each year or even month. A single
> level is generally fine for up to 100-1000 child nodes, but once you
> go higher than that it's better to introduce such an extra hierarchy
> level both for performance and ease of navigating the content
> structure.
> > ------ Projects (Node)*
> > ------------- Project Descirption Document (Property)
> > ------------- Project Planning Document (Property)
> > ------------- Project etc etc Documents (Property)
> > ------------- Team ( Node)*
> > ------------------------Team Name and Description (Property)
> > ------------------------Team Location (Property)
> > ------------------------Team Active Hours (Property)
> Will the teams be project-specific or more permanent entities that you
> just assign to different projects? In the latter case you probably
> want to store the team information higher up independent of individual
> projects, and use a (multi-valued) REFERENCE property to link from a
> project to the teams working on it.
> BR,
> Jukka Zitting

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message