jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Complex Hierarchy best practices
Date Mon, 19 Feb 2007 09:18:09 GMT
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

Mime
View raw message