You’re often told that Find (Officially Search & Navigation, but most of us just call it Find because it’s shorter to speak and to write ;)) is great and you should be using Find as much as possible, off load database access because database access is slower. That is true to some extend, but not always correct. Find is great when you need to search for content, especially in a free text search manner. It’s much more efficient when you have a keyword and need to find matching content for it, using Find will be magnitude faster than loading the content from database and do a check on every content, and still even much faster and more efficient than query directly from database. You can leverage it when you are looking for the content. For loading the content, however, it’s a different story.

If you are using Optimizely Commerce (Connect, B2C, or whatever you call it these days), you are likely using its serializable cart mode. That cart mode has been introduced 10 years ago (I still remember a cold winter day when I first introduced it to the OMVPs (then EMVPs) at a summit). It was introduced to help reducing the performance issues - most notably deadlocks with order system. Previously, the carts use the same database schema as with the orders, you have base information stored in OrderGroup table and additional, customizable data stored in OrderGroup_ShoppingCart, with a foreign key reference. It works great when it comes to functionality, but when your customer places an order, you need to do two things - saving their order to OrderGroup_PurchaseOrder and delete from OrderGroup_ShoppingCart - as the reference keys are updated in OrderGroup, you risk the chance of deadlock which increasing with your number of carts/orders, and your traffic. Serializable cart mode solved that by moving the cart data to a separate table - and you can probably guess it - SerializableCart. The static fields have their own columns, but the data - which is extendable & customizable - is serialized and stored in Data column.

Sometimes your website need some data migration. There should be a way to run it after deployment but before the site performs any other tasks. There are several ways to do it, but IMO it could best be handled with IMigrationStep. It is an hidden/undocumented feature that allows data migration. Each step is supposed to run once at the first start up to ensure data migration.

This is a snippet of code that I’ve used more times than I care to admit, but every time I have to look at my book at https://leanpub.com/epicommercerecipes - the chapter is free and can be read without buying the book. However that is quite inconvenient, so I think it is better if I put it to my blog for later usages - and maybe it helps you too.

For a quite long time, I have a advocate against the use of OR inside the WHERE statement of SQL query. Let’s dive into it to know why you should avoid it, and what is the right solution for it.

Cache is good. No, cache is critical - no performant website can go live without proper cache. But can you have too much cache? It turns out that having too much of “good things” can be bad. Sometimes, really bad. In this blog post, let’s explore how too much cache can be a bad thing.

For most developers, the usage of AspNetUsers ends with the APIs - you use the API to create, update, query and delete users - and that’s it. Performance is usually an afterthought, if at all. It’s an official library from Microsoft, it must have good performance, right? I wish I could say, right. As with case of ASPNET Membership (are you old enough to remember it?), this has many performance gotchas. And it can be a huge problem with your website once the number of users have grown enough.

A common table design that you might be familiar with, is to have an identity column, could be int, or long, or uniqueidentifier, and then, a clustered index is conveniently created on that column. An identity is, technically speaking, the perfect choice for clustered index - it is not null, it is unique, and in most case it’s small. But is that really the best choice?

It all started 5 years ago.

Have you ever track and debug a Heisenbug? It’s elusive bug that disappear when you try to find it. But how about the opposite of Heisenbug, the one that tracking the bug actually causes it?