How much do you let Sitecore (or other CMSs) manage?

Question

I have been wondering how much content you should typically allow a CMS to manage, in particular reference to user-generated content. I am thinking specifically of Sitecore, since I have an upcoming project that will be written with it, but this could apply to any CMS really.

Say you had a typical e-commerce site, with products for sale, and users could leave reviews for these products and also purchase the products which creates orders within the site.

I get the impression whilst looking at Sitecore documentation and around on the net that you could use Sitecore to manage every piece of content. i.e. Each product is its own item in Sitecore, but then every time a user submits a review it creates a Review item under that product. When a user makes a purchase it creates an Order item else in the content tree.

To me this sounded fairly horrendous at first. I would have just thought you would use a CMS for editor-drive content. I could understand having products as items if you must, but everything else I would put in a separte RDb which is tied to Sitecore via a product id. It's more work but surely if everything was placed within Sitecore you could have giant performance issues?

On the other hand, if it was all placed within your CMS you wouldn't have to have an additional data-layer, and you could probably make great use of the built-in caching of your CMS. It would be much easier to allow your editors to approve/disapprove reviews, since they could just manage it all through the Sitecore admin instead of you having to create a custom page for it.

Have you worked on sites that have always done it one way, or have you tried both? How successful did you find them?

Answer 1

I've not used sitecore specifically but my answer is based on experience from umbraco and EpiServer.

I've tried both and basically, it depends. If you need to query this data a lot - it should go in a custom DB because the databases behind most CMS's are abstract and difficult to query as you would a standard database. You will find yourself writing a lot of boilerplate code to get around limitations such as loose typing, empty values etc. This is due to the way a CMS's document types/pages are defined by the user i.e. custom properties. However going down this path you will now have to build an administration tool for this custom data which may or may not be able to integrate into your CMS backend. So you have to weigh up the options here.

Some CMS offerings (like EpiServer) will let you manage custom data sources from within it using a provider model to present relational or other data (XML, web service call) as if it were pages within the CMS.

These are your basic considerations, it is up to you to choose what is right on your specific project.

Answer 2

I've used Sitecore CMS and done some work with Sitecore Ecommerce Fundamentals. If you're going to build an e-commerce site with Sitecore, you'll want to use Ecommerce Fundamentals as its an pre-built e-commerce structure on Sitecore. Products, prices, delivery options, payments are done in the Sitecore content tree. If you want to add on customer reviews, you can extend the Sitecore templates to handle this, or you can wire up an external database as you mentioned and link them by their Sitecore GUID. You can manage as much as you want within Sitecore, so its a matter of knowing the volume of your site and expectations for what you're managing. Will you have several products or hundreds? What # of reviews do you expect? A few or tons? Sitecore has a know performance issue that when there are more than 100 immediate children under an item (think comment items under a product), Sitecore performs less efficiently for that item. I recommended you pose the details of your site to the SDN forum and get direct feedback from Sitecore-certified developers there.