Using Sharepoint as master data storage?

[duftstenen]

Hi everyone and thanks for your time. I’m not sure that this is the right forum to ask the question, but I can’t find any other forums that might touch this subject in general terms. I have tried to search the web for blogs and articles with topics on how the technical solution should look like, but with no luck.

My request is getting you guys’ thoughts on handling master data in Sharepoint as data storage. The deal is, today there are no central place where employee data is stored. It is a wish that an Employee Directory is made thru the Sharepoint solution, based on e.g. the profile database and mapping with attributes in Active Directory. The idea is fine, but my concern is, when we are talking about the expectation on creating master data, where the employee data properly should be available easily and in a flexible way for other system later on, wouldn’t it be a mess putting the data in Sharepoint custom lists etc. and not in e.g. SQL?

I know that you can XML export the data from Sharepoint. But what do you guys think of using the Sharepoint database structure and not SQL, as the master data?

You comments, thoughts on this subject is very appreciated, or if you have any suggestion on forums or communities where I can raise this problem.

Best regards
D.

 

[PatricktheAnalyst]

When looking at the profile data, Active Directory is really the master, SharePoint does regular synchronization (if configured) and that data is available through a web service. Many applications can take advantage of active directory to create visual reports fo the employee directory (ie Visio is one). I do not see a benefit to creating another list unless its needed for another program to reference it as a data source, if that is the case you definitely would not want to use SharePoint unless its an access 2007 application. You can report off the data from SharePoint with SQL Reporting Services etc.


Patrick

http://sharepointglobal.blogspot.com/

 

[duftstenen]

Hi Patrick,

Thank you very much for your reply. I can understand that AD in many ways should be used as the master data, as it is used as general access control etc. I know that the profile data in Sharepoint can be populated thru a AD profile import. However, and please correct me if Im wrong, I dont find the AD very suitable as be the master data source for employee data, as it might not be appropriate if any aditional information need to be added to the employee that is not in the default AD attribute schema, lets say marriage status or skill registration. I want only one place to update the employee data and possible pushed to other system afterwards.

It is the idea that the data in the future should be used in varios other systems, which might not be "Sharepoint or AD friendly". What about the solution having it in SQL, but using Sharepoint as the frontend? Note that it should be possible to change and update the employee data thru Sharepoint.

Regarding the SQL Reporting Service in Sharepoint, can this also export the profile infomation, or is it only for specific data sources in Shareponit?

Thank you.

Best regards
D.

 

[PatricktheAnalyst]

I think you can pull it out with RS and getuserprofile. I use this with infopath all the time. I suppose you could also create a view of the data from SQL but if you do that make sure you query with a nolock option.



Patrick

http://sharepointglobal.blogspot.com/