I never thought that I would have to write this article, but on a recent project, a fairly big agency thought it was a good idea to customize the Episerver schema.  I'm still not sure the reason.. but for anyone reading this, who are considering changing the Episerver schema DON'T.  In today's article, I'll explain why and explain some better alternatives.

A Quick Overview Of The Episerver CMS Database

Like most .NET CMS systems, Episerver uses an SQL database to store, retrieve and display all the data within your website. The database is the most crucial part of your CMS and without a valid database and connection to it, your website won't work.

As developers, we will need to add/edit and delete data from the database and to achieve this Episerver provides a number of APIs/ways in code of doing Episerver related stuff, so you never really need to look at the Episerver database yourself.  I'd roughly say that most developers will probably never need to access their database directly

What's The Harm In Changing My Episerver CMS Database Schema

First, changing your schema will very likely prevent you upgrading your CMS.  As Episerver release the CMS every two weeks this will cause you numerous headaches.  For those of you who don't fully understand how the Episerver database is created/upgraded, I suggest you read this article

To upgrade your database, as part of the upgrade process you will need to run a bunch of upgrade SQL scripts.  If you change your scripts you will very likely cause these scripts to fail.

Second, the Episerver dev team have numerous unit and integration tests they run before they ship the products.  If you change the schema you're effectively breaking tried and trusted code.  If you call Episerver support up and they find out you changed the schema, you'll also be on your own in terms of support as you've gone outside the rule book of building within the Episerver framework.

Lastly, if you ever get the unfortunate luck and work with me... I will consistently point out how bad an idea your decision is on a very frequent basis.  

But I Need To Store Some Custom Data!

Needing to store some custom data is a pretty common requirement and there are a number of alternatives. 

First, as you may guess DO NOT use the Episerver tables directly/DO NOT change them.. leave them alone!

The most common approach most companies take when they need to store custom data is to use a separate database store.  Depending on your needs you could go a NoSql route, like Mongo/Redis etc..  or you could go SQL.  On most projects I've worked on we tend to go with a SQL database when we need to store persistence data.

If you go the SQL route, I recommend using a separate database for your stuff.  This isn't vital but it will give you a good logical separation of Episerver concerns and your concerns.  You can also put all your data access code for your separate SQL database in its own class library, so your code base is easier to understand as well.  This approach follows more of an SOA or micro service, that each logical thing has its own store. 

The main reason companies don't want to use a separate store is cost.  If cost is an issue and you're working in the cloud, you can create custom tables within the Episerver database.  I've done this a few times, while conceptually it's not as clean, it will work.  If you need to go this route, make sure you prefix your tables with your company name to avoid future naming cashes in case Episerver adds a database table with the same name

If you are reading this and you still think you need to customize the Episerver database, trust me when I say this, your architecture will be wrong somewhere and you definitely do not need to go down this path.  If you find can't think of an alternative ask on the Episerver forums for a different approach/idea.  There are loads of people who look a the forums who can help you 

Episerver CMS Database Schema Takeaway

In 13 years of doing this, I've never needed to customize a CMS database and there's always been a better alternative/approach.  In case you have got the subtle hints I've been eluding to, DO NOT modify the Episerver schema, it's a bad idea and you will only screw yourself over in the long run :)