Reason for separate SQL DB?

Jul 3, 2012 at 5:48 PM

Was there a reason you created a separate DB for this, as opposed to using a similar data structure as Sitecore Alias?

Just thinking that based on requirement of having different versions & languages, it might be easier to manage in Sitecore.

Jul 10, 2012 at 1:22 AM
Edited Jul 10, 2012 at 1:29 AM

I originally created a Sitecore provider which did just that, It created a redirect item for each redirect, it had different schemes for automatic subfolder creation too. The problem is speed - it's very inefficient. Its not that big a deal when just dealing with a few hundred manual redirects, but performance becomes an big issue when you get into 1000+ redirects. I mentioned this in the comments section of my initial blog post about this module. In short, 2000 redirects as sitecore items took 4 seconds to load into cache. By comparison, loading 100,000 redirects from SQL into cache took around 250ms.

This big speed difference makes the generation of automatic 301 records possible. Because the mechanism creates a record of all urls when published, there will always be at least as many redirect records as there are Sitecore content items. This would generally rule out the Sitecore provider, but its easy for the SQL provider handle.

Key differentiators for this module are pipeline speed, UI customization which presents redirects for the context item, and automatic 301 generation. All of these things require a fast lookup mechanism which just wasn't possible with Sitecore item storage.

>> Just thinking that based on requirement of having different versions & languages, it might be easier to manage in Sitecore.

The module is not version or language aware. Urls are stored without the language prefix.  The link is between a published url and the item id it belongs to. There are so many permutations of site setups, languages, versions, prefixes and so on that it's tough to find a solution that fits all. A redirect does not belong to a version, its a separate process that links to the item that is live as soon as the redirect is created, either manually or automatically on publish.