CMS/E-commerce asp.net project: one database or multiple databases?

Question

Hi,

I'm currently working on an C#/ASP.NET project that will host several differents e-commerce websites, all running in the same application.

I use LinqToSql (moving to PLINQO soon) to access my database. The database contains both informations on the website structure (pages, ...) and the products/orders/users data.

My question is, should I use only one database for all the websites, or sould I create a new database (same model) for every new website?

I'm now using a single database (with SiteIDs in some tables) but I have a big security concern, I can't just backup/restore the database for ONE website if something goes wrong (e.g. somebody erase all the products on ONE website) and it's an important requirment of the application.

So I was wondering what are the good practices in that case? Is there big cons if splitting dbs? (I would have to make changes to several database instead of one in case of structural changes, but i guess i can make a db version/update system). How the existing CRMs are dealing with that? Is it a performance problem if a database server host a lot of different DataBases? A complex backup/restore tool would be better?

Subquestion: To make a website replication easy, I can also split the pure CMS data (Pages, Texts, ...) in one DB and the e-commerce data (products/categories/orders in another). Is it a good idea? It can be achieved by some select/insert functions but it would be easier by just copying a database of course.

PS: sorry for my approx. english ;)

Answer 1

If you are worried about having all your sites in one database you have probably answered your question. When I used to have them all in one database I used to be explicit that it would cost to get the database sent to them.

I would reckon if your clients will want regular access to the raw data you will need to split out the data. However if not then you should be alright.

As far as database updates go you should have scripts for doing the updates anyway to go from test to live systems so running across further systems should be alright. However it will create an overhead.

In short no right or wrong answer, if you can keep together and keep the clients happy then do so else split out and charge the clients the bit extra.