This week, I returned back from a client site to join my colleagues in a planning workshop for Sitecore 7. Our group already has one client moving to Sitecore 7, and we’ll likely have several other Sitecore 7 projects coming down the pipe in the next year, which means we need to be ready for it. There are a lot of things coming in this next release that are really cool for developers, but buckets are giving me the heebie-jeebies.

In planning for our upcoming projects, and deciding which of the features of Sitecore 7 we will want to make a part of our base offerings, it became clear as we discussed buckets and their implications that there were very few situations where I would want my architecture to use them. The Sitecore development team does provide some guidance on bucketing strategies. In general, buckets offer a way to store large collections of content without affecting performance. Buckets seem to make sense for very specific situations, such as a large set of error messages that have no logical groupings or for other types of data repositories (such as shared data sources) where there may be many similar types of objects that didn’t necessarily need a hierarchy. I’m not too worried about using buckets in those scenarios, but if authors began using buckets in the content tree, that would probably lead to several issues.

We all know about the “100” rule (give or take) for siblings in Sitecore. Around that number of siblings in a single node, Sitecore performance starts taking a dive. Buckets to the rescue?

No.

We didn’t have buckets before, and we solved that problem.  It was called document organization.  Have you ever put 500 items into a single-select drop-down before and asked a user to make a selection during a usability test?  Now take that same list and put it in a random order that is not alphabetical.  Now you have to add search just to find something in the list.  That is exactly what buckets do to my tree.  Obfuscate the data so much that I can’t possibly find something without knowing what it is already.

On the flip side, if you actually organize your content in reasonable folder structures, people who do not know the item they are looking for can find it via context. The web pages in the Human-Resources\Benefits\ path probably has the content you are looking for about submitting a form to your benefits provider.

Don’t get me started on URL formats. If you drop a content item that’s supposed to be a web page into a bucket, the URL is going to have a bunch of folders based on the bucketing storage mechanism. Sure, you can change the URL to a GUID, but that isn’t any better for search engine optimization. The bucket effectively removes the ability to control that URL for the item.

I’m sure you could put together a solution where a secondary tree stores content in buckets, and the primary website structure is controlled in a separate tree. Business logic could then programmatically tie them together.

Or you could just NOT use buckets and build your tree with some sense, like a normal person. 😉

A colleague of mine also mentioned something that sent shivers down my spine: Team Development for Sitecore (TDS) source control of a bucket. I can’t imagine what awful state my source control is going to be in once I start creating bucketed content for our skeleton tree. Of course, we won’t have real production content source-controlled in our TDS projects, but we’ll still need enough data to ensure we can test the search interfaces and views that are now available in Sitecore 7. That means hundreds of mostly empty folder items taking up space in my project and my source control, instead of a few test items in some planned folders. 

The saving grace in all this is that you can reverse your decision. You can unbucket a bucket. Still, I have nightmares of little buckets taunting me with their generated structure and enforced search dependence. So many buckets, all chanting at me: One of Us. One of Us. One of Us.

*shudder*

The solution seems simple: If I want to maintain my sanity, I’m going to need to be prepared to tell any client who wants to take advantage of this cool new bucketing feature to just stop and think about it for a second. Do you really need to bucket this content? With a little thought, could you organize your content better?  Do we really need 5000 items in the same folder? Is this content really content that should be  in the CMS?

Maybe I’m wrong. I’ll admit it: I haven’t played around with these buckets enough yet to really put them through their paces. They conceptually could have some uses. In the Small Medium Business (SMB) market, we aren’t usually dealing with millions of records of information stored in the content management system. These folks usually have other systems for that type of data already, and we are just integrating with those systems. Something like an Amazon-sized commerce site, running on Sitecore as their main product catalog, would need a way to contain all of that product information, and wouldn’t have the time to be constantly restructuring their folders. In that situation, I can definitely see bucketing providing some benefits.

Have you had any luck getting buckets into your projects? Is there a way to face this fear head on? Let me know!