> My instinct is to have a 'currentAssignee' property I had the same "rdbms-instinct" too. We have many thousand tasks and my experiments with jcr-sql2 have shown that querying in a big set with a where clause (e.g.: open tasks of employee xy) does not really scale well. So my next thought was to make use of path/hierarchy
-----Ursprüngliche Nachricht----- Von: Justin Edelson [mailto:[email protected]] Im Auftrag von Justin Edelson Gesendet: Dienstag, 16. November 2010 00:52 An: [email protected] Betreff: Re: AW: Shareable nodes vs weak references Clemens- This feels more like a reference/path use case than shareable nodes, but I can't quite put my finger on why. My instinct is to have a 'currentAssignee' property (probably single-valued) on tasks which points to the user. Also, modeling workflow state (open vs. closed) as a path segment seems odd, but maybe I'm just not thinking about it right. Justin > -----Ursprüngliche Nachricht----- > Von: Clemens Wyss [mailto:[email protected]] > Gesendet: Montag, 15. November 2010 17:14 > An: [email protected] > Betreff: Shareable nodes vs weak references > > Given the following data structure of projects and tasks: > project > p1 > tasks > all > t1 > t2 > open > t1 > closed > t2 > > and I then want to add the employees/task association (tasks assigend to > employees): > > employees > e1 > tasks > open > t1 > closed > t2 > > The task nodes (t1 and t2) should, of course, not be replicated. Basically I > see two options (of 5, > http://osdir.com/ml/users.jackrabbit.apache.org/2009-10/msg00238.html ): > a) shareable nodes > b) multivalued weakreference properties > > Which of these is better/more performant? Pros and cons of the two > approaches? I would opt for a)... > > Thanks in advance for your advices
