I never thought that I would have to write this article, but on a recent project, a fairly big agency I was working with thought it was a good idea to customize the Episerver database schema. I'm still not sure the reason.. but for anyone reading this, who is also considering changing the Episerver database schema DON'T. In this tutorial, you will learn why this is such a monumentally bad idea
A Quick Overview Of The Episerver CMS Database
Like most .NET CMS systems, Episerver uses a 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 a valid connection from your web application to it, your website won't work.
Often as a developer, you will need to work with the Episerver data. You may need to add/edit and delete data stored within the database. To achieve this Episerver provides a number of APIs that allow you as an implementor to work with the data. The APIs are an abstraction layer that hides the implementation details of how the SQL database works away. Developers should never need to access the database directly as everything you want to do, can be done via the API layer.
What's The Harm In Changing My Episerver CMS Database Schema
First, changing the Episerver database schema yourself will very likely prevent you from 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 to inline with a new CMS version release, in the background Episerver you run a bunch of upgrade SQL scripts. If you change the database schema then this installation process will fail ðĪŠ
Second, the Episerver dev team has numerous unit and integration tests they run before they ship a new version of the CMS. If you change the schema you're effectively breaking tried and trusted code. If you encounter an issue and then phone Episerver support, if they find out that you have changed the schema they will not support you. You will 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 SQL database. Depending on your needs you could go a NoSql route, like Mongo, or Redis etc... If you need persistence stoprage.SQL will be your friend.
If you go the SQL route, I recommend using a separate database rather than building a table inside the Episerver database. This isn't vital, however, it will give you a good logical separation of Episerver concerns and your business logic concerns. If you ever need to migrate the site having a separate database will make life much easier. You can also put all your data access code within a separate class library, so your codebase is easy to understand and easy to migrate from! This approach follows more of an SOA or Micro-service way of thinking, each logical thing has its own store.
The main reason objection for not wanting to use a separate SQL database is cost. If cost is an issue, 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 custom SQL tables with your company name to avoid any future name clashes. If Episerver added a database table with the same name as yours the site will break ðĪŠ
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 can't think of an alternative approach to solve your problem, ask on the Episerver forum. There are loads of people who look a the forums who can help you. In 13 years of doing this and I've never needed to customize a CMS database. In case you have not 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 ):) Happy Coding ðĪ