Pros:
A great data model once you get used to it. It gives you somewhere to start and an initial mindset how to store in contents. I especially like the ability to store in the file system. I have used to ability to reduce the storage needs of binary files. Changes on the title and description can be done without copying the binary data since you can just copy the file name of the previous version. Ala "ln -s" in Unix. Thanks to Luke P for pointing this out to me.
Ability for other packages to use your data such as search.
Cons:
Poor documentation but I believe Roberto Mello is on the way to rescue. This is evident as file-storage, news, etp, etc. have different strokes in inserting and fetching data. Some directly inserts into the cr_items and cr_revisions, still some use the CR db apis.
You have to aware not to touch the content of other packages intentionally. So delete cr_items/cr_revisions will nuke out the content of other packages too.
Others:
Regarding the parent and child relationship I think its possible to use the parent_id column of cr_items. Right now the parent_id is used to reference the folder_id of cr_folders. But from what I remember there is no constraint for to use another reference. For example the parent_id of cr_items can point to another item_id for cr_items. Thereby grouping cr_items. Or you can just create a cr_folder and treat each folder as a group of items. CR is generic enough for you to use to the way you need it, which is a great advantage.
Having this generic tables like cr_items, cr_revisions, acs_objects may at first be confusing. But for me I think it a right step, except for the performance penalty since this generic table will handle many packages. The negative effect is more rows of data in a single table and joins to package specific tables.
