Unanswered: Need some thoughts on an emerging trend with SharePoint
I was hoping to elicit some feedback on a trend I am seeing in the Portal market, and specifically with SharePoint development.
If you are not familiar with SharePoint, there is a data table abstraction within SharePoint called a "List". Lists are used for storing data (duh!). However, they are built using the SharePoint front end, and the data entered into all lists is stored in a few tables in the SharePoint content database.
What I am seeing happening is SharePoint gurus reccomending AGAINST storing your relational data within database tables, and within SharePoint lists instead. I am not sold on this approach, and it actually makes me think we are taking a step backwards with regards to persistent data storage and best practices.
- Lists cannot be natively related to one another, however they support "lookups"
- Anyone can create a list...and repeat the same data all over the enterprise.
- Lists are maintained in two tables within the SharePoint content database using meta-data patterns.
- Portals contain a multitude of sites. Users and portal admins can create lists all over the place, thus spreading related data over a wide swath of the enterprise.
Is it just me, or are SharePoint pundits absolutely CRAZY to be recommending persistent data storage using lists? I see nothing but problems arising from this approach.
I apologize beforehand if you have not worked with SharePoint and Lists, as this post may not make much sense to you.
I don't know about Sharepoint lists but I do know EAV and OTLT and it sounds similar.
Have a quick google of EAV (Entity Attribute Value) and OTLT (One True Lookup Table) and see if that matches up to your lists. Rudy has some good links. The general gist is that on this site just about everyone bar one vocal dissenter think EAV and OTLT are Spawns of the Devil. Even the dissenter probably wouldn't like this this since he doesn't trust users to control the "schema".
I have a fair bit of experience with sharepoint 2007 and one thing that has been a major issue is the disaster recovery of sharepoint, which by all accounts is a nightmare. Have they tested their disaster recovery?
Things to consider are:
1. There is no way to just restore the data you want, you have to rebuild the entire farm (in my experience anyway).
2. What happens when you have millions of rows of data, how will sharepoint perform compared to SQL server?
3. By default the security of sharepoint is very open, have they locked it down well enough?
4. Like you say there is bound to be lots of duplication of lists, departments not communicating with each other ect.