This project has moved and is read-only. For the latest updates, please go here.

Why requires SLK a separate database and is it not 100% SharePoint?

Topics: Developer Forum, Project Management Forum
Mar 12, 2011 at 9:03 PM
Edited Mar 12, 2011 at 9:04 PM

I was wondering, why SLK depends on a separate database. Wouldn't it make sense to have the admin and management data available as SharePoint ContentTypes which for instance are used when creating lists? The reason for this question, is that I've installed SLK today, expecting to find a 100% SharePoint Learning Solution but instead I've found a .NET application with a deep SharePoint integration and a separate SQL database. Has the idea of a 100% SharePoint Integration been tackled previously and did it turn out to be too difficult or problematic and if so, for what reason(s)?

Many thanks, Marco

Mar 27, 2011 at 9:34 PM

Great question.

I wasn't part of the team which orginally created SLK so I don't know for sure the reasons, but this is my opinion on this.

1.    In my opinion, having a separate database doesn't necessarily mean that it's not a real SharePoint solution. There's plenty of parts of SharePoint itself which have separate databases. Search immediately springs to mind which has several databases, and other service applications do as well.

2.    Although lists are very flexible, they are not relational databases. Some data just works better in a relational database. If you look at the SLK database there's around 40 tables with all their relations. This would be quite tricky to work with in terms of list.

3.    Security. In all these tables users should only have access to their own data. Although possible through item level permissions, this is going to be tricky to manage.

4.    Performance. Given the complexity of the data, list access is likely to be a lot slower than database access.

5.    Probably the killer reason is that the SLK can cross site collection boundarys. In this case you need a separate repository to store the data and a database makes a lot of sense here.

Given all that, I have started thinking about how to run purely within SharePoint so that it could be used in a hosted environment as a Sandboxed solution e.g. Office 365 for Education. This would take a lot of work to sort out though.


SLK Coordinator

Mar 28, 2011 at 8:12 AM

Hi Richard

Many thanks for your reply. I would basically agree with you and the five possible reasons. Still I believe that with SharePoint 2010 a lot of the MOSS shortcomings have been taken care of.

Performance, for instance, shouldn't be a problem - also not in scenarios where larger multinationals end up having a couple of thousands entries in a list. However, before I've said that, I better develop a prototype and take it for a test drive! Probably you can optimize at one point in time with some kind of list entry archiving algorithm.

Also, I believe security probably is easier to handle as you can assign permissions at item level and when you assign those permissions, you can benefit from claims based authentication and integrated your forms based users as well (extranet E-Learning solution). With the content type hub and proper solution provisioning, I guess it would not be a problem to cross SiteCollection boundaries and create/distribute the necessary ContentTypes and Lists upon feature activation.

I believe there might already be a couple of (more expensive) solutions out there that really try and provide such a SharePoint LMS. However, it still make sense to think about a simple yet 100% pure SharePoint approach to E-Learning that builds on the SCORM-Player the ships with SLK.

Many thanks, Marco