sharepoint lists design practice

I am new the sharepoint development, hope my question makes sense,

using sharepoint 2010, structure of the application I am working on is like below:

• site collection root
  • some lists and content types that are common to all sites below.
  • a site for doing something with x-type projects
  • a site for doing something with y-type projects
  • a site for doing other stuff not directly related to the projects but may be indirectly

if I was designing a tratidional database application, I would have a BaseProject entity, and would discrimi开发者_运维百科nate the sub projects by a projectType field or even would have subEntities which are related 1-1 (kind of inheritace relationship) to the baseProject entity-if normalization issues bother me much.

people around suggest to have seperate lists for x,y projects which have different workflows, document templates, different users, etc, and isolate the contents of different sites, aggerate the datas when reporting, not even to think of inheritance-like relations between entities but this means the relations from common entities would need to be made seperately to the different lists of projects. and many look-up lists would be repeated around different lists of "project" entities. so expanding the data model would be difficult in the future. and for the reports that are interested in whole scope of the application, would need to aggregate the lists scattered among the sites.

if I design the lists to be more expandable later on

1. only one baseProject list in root site with a projectType column: I would have to filter every lists that contains more than what I need in a specific site

2. one baseProject list in root site and sub-lists for other types of projects in sub sites: I would need to syncronize the data between base list and sub lists. to have all the project items in baseProject list.

the question is: what are the best practices to design sharepoint lists to model inheritance between entities ?

regards..

It is very difficult to answer specifically without a lot more detail on the project. Building your site model is a complex task that is specific to a particualar projects requirements.

In simple terms, if a list has different processing associated with it, then it is a separate list. If you need to indicate similar data, then use defined fields, which will maintain your consistency. Reporting can be made to work whatever your structure, so treat that as a lesser issue.

But the primary focus for site design should be the functional behaviour of the business. If you match that correctly, then everything else will eventually fall into place.