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!