At least once on each my SharePoint projects over the past year my clients have asked me if SharePoint 2010 would help with any of the things we were trying to accomplish with lists. The answer in every single case was “yes”, though I couldn’t always say much since we were under Microsoft NDA until SharePoint 2010 Beta was released. It’s a little painful looking back on the custom development I had to do in MOSS/WSS 3.0 (even SharePoint 2003) projects to achieve what SharePoint 2010 lists provide out of the box. Well, only painful because it was time that I could have spent on my clients’ other high priority tasks.
This post is dedicated to those clients. :)
Note: All screenshots and descriptions are based on SharePoint 2010 Beta.
List Relationships
SharePoint enables relationships between lists via Lookup columns. I didn’t pick up SharePoint until the 2003 version, so I know lookup columns have been included at least since then (I *think* 2001 had them). In SharePoint 2007, creating applications and views based on those relationships is still custom development. For example, master/detail views are somewhat possible with some of the fancier UI configurations such as web part connections. The most common method I’ve seen and used is by creating a custom list display form (DispForm.aspx) for the “master” list item and adding a data view web part (DVWP) for the related “detail” items. This would be done in SharePoint Designer and requires knowledge of XSLT and XPath to render the detail items correctly (the DVWP GUI interface never gets it exactly right for me) and a little CAML to configure the detail section’s filter.
Enter SharePoint 2010 list relationships. When a column is created as a Lookup field, you have the option to enforce a relationship behavior with the parent list. Part of that behavior is the ability to restrict deletes in the parent list if there are related items or to cascade deletes down to the child lists. Note that creating a relationship also requires that the column be indexed.

Once the list relationship is established, it is possible to created advanced views on the built-in list forms. For example, if I have a Contacts list with a Lookup column to an Offices list, I would like to show any related contacts when viewing a particular office. To do this, I browse to the Offices list and access the Default Display Form from the Form Web Parts option under List Tools in the ribbon. That directs me to the display form (DispForm.aspx) for Offices. The ribbon UI on that page contains an Insert section under Page Tools where I can add any related lists; in this case, Contacts.
Adding the related list adds a list view web part on the display form page with a built-in filter to only show contacts related to the displayed office. When users click on a specific office any related contacts will automatically be shown.
Projected Fields
Over the past year I have done a lot of work with custom list forms and views of related lists in SharePoint 2007. One of the common requests I get is to show additional fields from a Lookup column’s parent list on a view of the child list item. For example, if a Contacts list has a Lookup field referencing an Offices list’s Title field, a requirement may be to also display the office’s location and phone number when viewing a list of contacts. This usually requires a custom view, such as by joining data sources in a data view web part with SharePoint Designer or .NET development.
Projected fields in SharePoint 2010 allow additional columns from related Lookup lists to be “projected” onto the view of the child item. Using the same example where a Contacts list references an Offices list, the Lookup column has built-in options to project additional fields from Offices to Contacts. The additional fields will be prefixed with “Office:” to indicate they are coming from the Offices list.
Validations
Previous versions of SharePoint allow list fields to be marked as Required. In addition, different column types had specific validations, such as maximum characters for text fields and min and max values for number fields. However, more advanced validations with formulas or business logic require custom development. SharePoint 2007 has several options: list event handlers; custom list forms; JavaScript.
SharePoint 2010 introduces both list and column-level validations using formulas that are configurable through the UI. These formulas are similar to those used in Excel and calculated fields. Each formula can also have a custom message displayed to the user if the validation fails.
According to this post on SharePointDevWiki.com, regular expressions are not supported in the out-of-box validation formulas.
Additional information:
Unique Column Value Constraints
In SharePoint 2007, to ensure a particular column contains unique values for every row requires custom development, usually with list event handlersor custom script on the New and Edit forms that call a web service to validate unique values. However, using a script in this manner would not be used in the datasheet view, whereas list event handlers would still work.
In SharePoint 2010, this is a setting on the field configurable through the UI. Note that enforcing unique values requires that the column be indexed.