My blog is back, welcome!
Let’s get straight to the point FindPagesWithCriteria is bad for you. It basically looks up the database to find the content that match your criteria. Because the search is not exact match but basically LIKE %abc%, which means every time you call FindPagesWithCriteria a full scan will be performed on your tblContentProperty table. IF your property is stored in a LongString column, things get much…
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…
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.…
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.
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.
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.
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…
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.
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.