This is something that I’ve told people more times than they really want to hear. Sure, SharePoint sits on top of SQL Server, which is an excellent database, but SharePoint itself is not a database! So is this a dire “abandon all hope, ye who enter here” message? Absolutely not. With planning and forethought, you can build quite nice applications in SharePoint that act in a database-like way. What it does mean is that all of the old rules still apply.
When I think about this, I’m always reminded of the Rules of Data Normalization poster from Database Programming & Design magazine by Marc Rettig which was hanging in one of my colleague’s cubes in the late 1980s. (Through the miracle of the Web, I was actually able to find this picture of it!) Though I can’t recite the rules from memory, it has informed my database and now custom list designs to this day.
- Eliminate repeating groups
- Eliminate redundant data
- Eliminate columns not dependent on key
- Isolate independent multiple relationships
- Isolate semantically related multiple relationships
I’m not going to go into the details of what each of these rules means (a quick search on the Web or an introductory Computer Science course will explain them to you). These rules and the nice 80s colors are cool, but what does this mean when you develop SharePoint applications today? Well, quite a few things.
- First and foremost, make sure that you build your lists following these rules. One key flaw in SharePoint’s architecture (it’s there for good reasons having to do with Office compatibility) that forces violation of the rules is the Lookup Field Type. Rather than storing the ID of the referenced item, the text value is stored. Try to avoid using the Lookup Field Type directly and…
* Don’t edit the default forms directly — take a copy and change the copy. You never know when you might want to revert to the original form.
* Change the forms associated with the list by right clicking on the list container in SharePoint Designer, Properties, Supporting Files tab. Making the change here will cause a redirect to your custom form even in places that the original form is requested.
- Handle deletes elegantly. There is no hook for workflows in SharePoint Designer to trap on a delete. However, if you build your forms well, you can provide delete capabilities that you can trap on and handle. There’s no such thing as cascading deletes in SharePoint lists (it’s not a database, remember?), so you’ll need to do the work yourself. If you’ve followed the data normalization rules well, this should not be too onerous a set of tasks. One simple way to protect yourself is to just disallow deletes in lookup lists. This means that you will need to provide some administrative function to handle them, but you will avoid simple breaks to the application. Be sure to…
- Teach your users the value of all of this. If you build your forms well, the amount of education ought to be minimal, but you may want to explain your methods so that they understand how it all holds together. Why? Well, if they don’t understand, they may try to do things to get around your good planning, which will make it all fall apart.
I’ve written many posts in the past that have snippets of how to do each of these things, so if you have questions about any of the details, take a troll back through my old posts or shoot me your questions.