Typically, those kinds of statements are made by SQL "enthusiasts" (zealots?). To quote from the article:
"SharePoint is very successful because you're removing levels of impedance, and a lot of the DBAs hate SharePoint for those same reasons," says Demsak. "Basically, you're storing everything in a BLOB and you can't relate to object relational mapping, and you can't do good entity relationships, you can't do relational models because there's all sorts of problems when people try to extend that SharePoint model past where it's supposed to go."
Mr. Demsak, I disagree.
Does everything belong in SharePoint? No. SharePoint isn't a high-volume transaction processing system. And there are other things SharePoint isn't. But the ideas that SharePoint stores everything in a BLOB and can't handle entity relationships is simply not accurate.
First, SharePoint does not store everything in a BLOB. SharePoint has a schema for everything it stores. That schema and data may coincidentally be stored in a BLOBish format at the SQL server level, but that's absolutely irrelevant. Who gives a dead rat's rear end HOW SharePoint persists data??? When we're dealing with SharePoint, we don't deal with SQL server. That's the beauty of SharePoint (one of them, anyway). When we deal with SharePoint, we deal with objects, not databases. Remember all those opinings of early OO programmers? "When are we going to get a good database system for persisting objects outside of an RDBMS?" SharePoint is your answer. And that's a good thing.
Second, SharePoint OOTB can handle the parent-child type relationships you'd typically express in a multi-tabled RDBMS through site columns and multi-valued fields. What it would take you five tables, five primary keys, and four foreign keys in SQL server, I can do in one list in SharePoint. (For flexibility, consistency and extensibility, I wouldn't recommend doing it in one list - but you can.) And it has bult-in data entry screens, views and filters. And it has built-in data integrity rules. And it's searchable right off the bat. And users can subscribe to alerts on my list. And people can add it to their RSS feeds. And...and...and...all right OOTB.
As for referential integrity and joining tables, Mr. Demsak is slightly correct. SharePoint doesn't do an outstanding job of enforcing cascading referential integrity contstraint changes OOTB. In other words, if you remove an item from a choice or lookup field in SharePoint, SharePoint isn't going to cascade an enforcement of that change to all the items in the list - so you may wind up with some list items referencing a choice or lookup item that no longer exists. But just because SharePoint doesn't have this feature OOTB doesn't mean it SharePoint can't do it.
So how do you get SharePoint to enforce cascading referential integrity constraint changes? Create a custom field type that enforces referrential integrity. Heck, CodePlex may already have one.
SharePoint also doesn't have a good mechanism in the web-based GUI for joining two lists together and viewing the resulting data set. But there are options. I generally dislike Access, but Access has found a new niche with SharePoint. Access can link to SharePoint lists - and it understands the foreign key references. Hence, Access is a great mechanism for joining related lists in SharePoint and generating views and reports on the resultant data set.
I'm the first guy to say SharePoint isn't for everything. But SharePoint is an incredibly powerful application development platform. Learn to leverage it.
No comments:
Post a Comment