Sitecore : Options for storing/querying custom data used by sitecore CD

0
votes

This (below) has been a common problem/debate on most of my sitecore projects.

Problem:

Sitecore web site creates/uses the custom data such as polls/quiz/user-journey/comments etc.

Solutions:

One option to solve this problem is create a custom DB table and use Entity Framework fro CRUD.

The other option is to make a copy of master database (as data) and use Sitecore API for CRUD.

The benefit of 2nd option could be out of box API usage, workflow etc.

Has anyone faced this issue and what's the best way to solve this?

2
sitecoresitecore8
Feels icky to me whenever I think about storing data inside Sitecore and therefore I usually pick a secondary DB. For a recent project, we just used xDB's MongoDB instance b/c it's so much easier to just start storing data than SQL as you're not about deploying schema too. – Jim Noellsch

2 Answers

2
votes

As you know there is no blanket solution for all projects but I believe this option is the best for most projects.

Option 3: Custom DB + Data Provider

  • Create a custom database as you have said in option 1.
  • Use a data provider so that the items can be indexed/searched easily (depends on your requirements, see additional benefits below)

Pros: - CD's do not depend on the custom DB which is a big advantage over option 1. - If you need to do any transformation to the items as you publish them you can, same applies in import. (in the instance you are connecting to an external/existing datasource that you want to transform)

For more info check out this: http://www.sitecore.net/learn/blogs/technical-blogs/john-west-sitecore-blog/posts/2012/05/when-to-implement-data-providers-in-the-sitecore-aspnet-cms.aspx

1
votes

We also have this challenge all the time. What I personally learned from experience is that when the requirement is fairly small, you have better to choose option one.

However, when the requirement is not a small thing, especially in interactive scenarios like what you mentioned, you have to ask yourself questions like: "what if later on client wants it multilingual or what if they need some sort of statistics and analytics on the result? Don't I want to take advantage of stuff like WFFM or Analytics?" In such cases you may better think it over and weigh the pros and cons and possible scaling options in the future (because practically sitecore projects are not for small scale websites). For example when collecting large amount of data you definitely need Lucene/Solr and Item Buckets.

Luckily in recent version of Sitecore you have MongoDB option which is a good option for collecting interactive data and stuff which are not well-structured and prone to change in structure in future.

Edit:

There is also an ORM tool called Glass Mapper, similar to EF, if you are interested. While EF works great with SQL server, Glass Mapper works with Sitecore Data Repository in the same way but it may introduce a bit performance drawbacks to your code.