Accessing the Data in Sharepoint

I've been spending some more time investigating on how to develop applications in Sharepoint. As said earlier, one question is always: Where to store the data?

In a standalone Application, I would obviously use a SQL Server or some XML Files, but both do not really seem fit with Sharepoint, as Sharepoint already has a mechanism for data storage - Lists and Libraries.

From here, it is worth looking at the White Paper for Microsoft's Fantastic 40. This document contains some information on how Microsoft built their templates, but to me, it also looks like Sharepoint is not made for "real" relational data management. I like the part where they use JavaScript to set an ID. Nothing against JavaScript, but that's not really what i'd like to use for anything important.

Jose Baretto has two interesting blog posts. One deals with Sharepoint Application development in general. For me, Point #2 was especially interesting:

When you develop your application, there's usually a database (or a few) that goes along with it. In the early stages of your application lifecycle you will define what data you need to store and that will end up in a set of tables somewhere. Your data architecture team will define what the data should be and your database team will eventually define the tables, columns and views you will eventually implement. In the end, your ASP.NET application will be tied to a database server somewhere by something called a connection string.

If you're using SharePoint, you get a place to store your data. No direct SQL Server access. No connections strings specific to your application. Instead of tables, you get SharePoint lists and libraries. You can create custom lists with custom columns that look a lot like the tables. You can also have links between lists like using lookup fields, which are very similar to a foreign key in a database table. When you deploy your application and create a new instance of it, the data elements are there.

This is nothing really new, just reassuring me that my plans for the data storage are indeed getting a bit more complicated. The only "good" way is to use Sharepoint lists, as they can be easily deployed without creating external dependencies. His second Blog post deals with deployment, and it essentially encourages the use of "no-code" whenever possible.

You should promote the use of no-code SharePoint applications. Those are the templates and solution definitions that are based purely in metadata definition, like columns, lists, views, pages and workflows that carry no custom code. If your package (templates and site definitions) has only XML/ASPX files and no assemblies, that a good indication that your risks are low.

It is true that this is more a security concern than a technical one, but from here I think i'll look into more ways to achieve my tasks with the built-in means of Sharepoint. This also means: No SQL. Instead, it is possible to use CAML (not to be confused with the programming language) to query data.

For CAML, Microsoft has documentation on MSDN, which i'll give a read next.

As said earlier, Sharepoint is an Application Platform. It is an interesting technology, even though sometimes I indeed have to question if it's really suitable for every business application. I'll guess i'll know when i'm done with my test project...

Comments (2)

BeyersOctober 14th, 2008 at 00:18


It's been a while since this blog post, so I was wondering, what is your response now to your last statement:

"I’ll guess i’ll know when i’m done with my test project…"

mstumOctober 14th, 2008 at 10:43

Over the past year, I've tried a few different things. I'll make a few more Blog posts within the next few weeks, possibly mid-November. But essentially, it boils down to creating SPLists and querying them with CAML.