modelling question (from RDBMS perspective)

[darionis]

I was thinking about application design in alfresco. I come with RDBMS background and relational type of thinking is somehow stuck in my mind. Obviously, alfresco requires different approach so I would like to ask few questions an discuss possible answers.

First of all I am not sure how to work with relations, most basic ones (many-to-one). Let's say I have to store "document" but I need to know it's "kind". "Kind" also has some attributes that are relevant to the document. In RDBMS app that would be implemented with foreign key (and a join), so I would be able to search for documents by property of it's kind. So, my first attempt in Alfresco, is to model two distinct types and make association but that makes searching difficult or impossible: a single lucene query that would find all documents that are contracts which are 'above 100K$' ('above 100$K' is attribute of contract kind). Other option is to store it as a flat data (like 1st normal form in RDBMS) but it also has maintenance  drawbacks.

I know that CMIS provides for SQL-like queries but I find it awkward, particularly when it comes to aspects. I also appears to me that CMIS queries are slow.

Is there a third or fourth option? Basically my problem is that I'am not aware of trade-offs between approaches, what I get and what I loose in terms of ease-of-development and also more important, performance.

Another problem I face is when I retrieve a document, I need to load all it's associations ("kind", etc) one-by-one and it may be cumbersome.

Has anybody got a suggestion or what would be a alfresco way of dealing with this?


Thanks!

[mrogers]

It helps (I think) to think about an object model rather than a RDBMS when configuring alfresco.

So I see that you have translated your "kind" to "type".   You also need to dig into your requirement to see if you have any subtypes - you probably do.   And then if you have things that are not related to the type of document or are optional then those become aspects.   Then you can work out how documents relate to each other.

My advice i've given previously on these forums is to try to model your documents and see how far you get.   If things become hard or un-natural then you are either unfortunate and have a difficult problem or have made a mistake in your model. 

CMIS query performance can be a factor but just as with SQL, different queries will take different times to execute.    I'd suggest that you decide upon your model first and then worry about optimising your query next. 

[afaust]

Hello,

your concept of a "kind" would usually be modelled with categories in Alfresco. Categories provide hierarchial "tags" that can be applied as simple properties to the node (no object-object associations) and can be used in FTS queries (Lucene or SOLR) to search for any level of the hierarchy, e.g. you can have a query for "all documents that are contracts" but can also drill it down to "all documents that contracts in the above 100k$ or between 100 and 150 k$".

Have a look at <a href="https://wiki.alfresco.com/wiki/Classification_And_Categories">Classification and Categories</a> in the wiki to learn more.
Since Alfresco 3.4 there is also a category administration tool in Alfresco Share which allows simple management / addition of categories that are dynamically made available to users in the form UI.

One general suggestion though: I personally would refrain from adding custom categories in the "cm:generalclassifiable" tree of categories. It is best to have one category tree per classification concept as you can configure the form UI to limit selectable categories to a specific (main) tree. Since you would be using sub-trees if adding to "cm:generalclassifiable" you can't restrict your users from selecting arbitrary categories instead of just your "contract kind" categories.

Regards
Axel