Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
    
How many levels are there in your relational data? –  Abe Miessler May 30 '12 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 Jun 1 '12 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.

share|improve this answer
    
+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 –  Gennady Vanin Геннадий Ванин May 31 '12 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. –  marcus.greasly Jun 1 '12 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?

share|improve this answer

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

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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