I have several lists in Sharepoint I'd like to link/view/query together, but I find it difficult to edit relational data with the same ease as could be done in e.g. an Access database (subforms, custom queries etc). I've been looking at related lists web parts, changing edit/view forms, creating infopath forms with repeating secions etc.

Does anyone have tips on good ways to get SP to work with this kind of data, without needing to implement custom web application with SQL backends etc?

  • How many levels are there in your relational data? Commented May 30, 2012 at 23:36
  • I.e. an infopath form with three levels of nesting. How do you map it with SP list(s) without simply using them as containers for xml data?
    – sptek
    Commented Jun 1, 2012 at 20:32

4 Answers 4


Developing solutions in SharePoint. Rules thereof.

  • Rule #1 it's not a relational database.

Yes, it's built on a RDBMS. And it has some simple RDBMS functions.

But... if you're building a solution and wanting to use RDBMS features, use a RDBMS. Map the data through BCS or point an Asp.Net at it to provide an interface. You can have lookups on lists from other lists and that's pretty much your lot in SharePoint.

Reporting on lists with lookup lists? Probably use Excel - pull the data in and and use it to generate some pivot tables and graphs.

  • +1 though Sharepoint is NOT built on a RDBMS, especially in part of "R" and "M", it stores management and user data in "DB" in XML format extracting them for its own "M" and servicing user's data Commented May 31, 2012 at 5:21
  • Yeah, what I meant is that the fact SQL Server is used doesn't translate to what's presented though the SharePoint API. Commented Jun 1, 2012 at 0:30

Relationships are handled in SharePoint by using lookup columns. Suppose you have a Customers list and a Regions list. You would define a Region for a customer by creating a new column on the list of type 'lookup'. Point it to the Title column of the Regions list. You can do this right in the browser.

Lookup columns have certain annoying limitations that will frustrate SQL-minded users, but that is the best way to handle list relationships among SharePoint lists.

This is a pretty basic topic in SharePoint - does this answer your question or am I missing something?


SharePoint offers some Relational DB features like Referential Integrity,Unique Keys and Joins.

Check this out for more details : RDBMS Features in SharePoint 2010


Plz use Infopath Designer for structuring your lists which is awesome (as autoantonym) WYIsWG XML editor of XML-based data and schema of Sharepoint Server forms.

It is part of MS Office suite and Infopath forms may be rendered by Sharepoint Infopath Services without necessity to have Infopath installed on client.

It is great for creating structured multi-level complicated list (which is synonym of XML schema) but not for relating, joining or merging lists. Though the latter is more the problem oа Sharepoint itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.