Kamna Jain wrote:
Hi All,
This question "might" be related to the thread that has been active in the
past couple of days about the data model.
We have a similar situation with the only difference being that we want to
create lists or collections (like Groups) of certain pre- created Objects.
The Object as a whole may/will belong to more than one such collection -
which means that if we were to use a Document to link a Collection and its
contents, then every document will have a COPY of the same object and this
is definitely not desirable for good performance - Right?
Right. Any duplication (except for backup purposes) is bad.
So, in that case, we have 2 alternatives:
1) Use the techiniques used in XWiki to create Groups: each group has
objects of class XWikiGroup with just one field that refers to the Member
name. OR
Yes, this is somehow similar to the Foreign Key concept in databases, so
it should be a good way to approach your problem.
2) Use XWiki.getHashmap() and add the Collection and
its members to the
hashmap (as the Key and Value resp.)
The XWiki API indicates that the option #2 must be used in xwiki when
Objects can not be created.
My Question is:
-> Even though I could use option #1 and create objects and add them to the
document that would represent the Collection, can I still use option #2
because I think that it will provide better performance. Am I right in my
assumption? What should I do?
#2 is a bit faster, but it does not provide persistence. When the
current request is over, that hashmap is gone. Given the fact that you
probably have to store your data in a database, in the end you get
almost the same performance as #1, but you have to reimplement what the
XWiki platform already offers.
When using a platform (any platform), you have to get used to the best
practices of that platform; this is true for XWiki also: although some
might be used to low level improvements of storage and SQL queries, and
feel that they know better how queries should be written, XWiki offers a
simple, high-level data model that should be used. The Google BigTable
model was also received by some with dismay, since it doesn't follow the
classical SQL principles.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/