Re: Philosophical question about many-to-many relationships between SharePoint lists?

Patrick Halstead — Mon, 01 Aug 2011 23:34:08 GMT

Hi ThoughtProcess,

SharePoint and InfoPath work well with relational databases. I don't think there's any "new" approach in SharePoint that implies you can't use SQL.

My experience is that most people start off in SharePoint and then add SQL after they scale beyond 10k items. SharePoint lists are not going to scale well beyond about 10k items.

SharePoint pages can be easily configured via SharePoint Designer (data views) to show relational data. InfoPath also works well with SQL but the best SOA practice is to use a Web service.

Hope this helps you,

Philosophical question about many-to-many relationships between SharePoint lists?

ThoughtProcess — Mon, 01 Aug 2011 18:00:21 GMT

Disclaimer: Yes, I know this subject has been beaten to death. I've been reading as many posts as possible (and I really, REALLY appreciate the patience of the Qdabra staff with answering variations of these questions over and over again). Despite my reading, I still have a few questions about my specific application (MOSS 2007, if it matters).

My client has a physical workflow that goes a bit like this:

Executives decide on release deadlines for the next generation of the company's products (we'll call them "widgets").
The Engineering staff negotiates with the executives to determine which features can realistically be included in the next generation of widgets.

If I were modeling this as a flat relational database, I would think of this in the context of three tables:

A table of the available widget "trims" and their release deadlines.
A table of widget features
A table that connects widget generations with their corresponding features, through the use of foreign keys on tables 1 and 2

Using this primitive layout, it's pretty simple to ask the question "what features will be in the next widget?" as well as "what trims of widgets have this particular feature?"...

If I wanted to model this relationship in SharePoint My initial, shoot-from-the-hip thought is to create lists that look similar to the SQL tables above. List 3 would have two columns--column 1 would have a link to an entry in Table 1, and column 2 would have a link to an entry in table 2. At least on paper, I think this would allow for a many-to-many relationship.

Ideally I want to make sure that I'm implementing this type of relationship using SharePoint's paradigms rather than traditional relational database paradigms.

Any thoughts about what I can (or should) do for this situation?

Thanks!

Newbie Questions

Re: Philosophical question about many-to-many relationships between SharePoint lists?

Philosophical question about many-to-many relationships between SharePoint lists?