White Label Ecommerce app. Shared or Individual dbs

Currently I'm working with an in house white label cms that we resell to multiple clients and it all runs from the same box/db.

I'm just looking at converting this to have an ecommerce version that we'll run alongside it.

I'm wondering whether there will be an issue keeping all the products/categories/orders in one db or whether it would be advisory to separate each instance of the site into its own db for this.

These white label instances will only be sold to smaller companies that probably wont have masses of traffic/products and are looking for a simple ecommerce site. Anything larger will definitely get its own hosting and db.

But for smaller scale stuff do you think a single db will be ok?

@Tim: Aye I agree completely, however as I'm working from an existing codebase all of the site specific filtering code is built in. All I need to do is add a couple of fields to each table and the backend will already take care of all that filter for me.

Also the codebase I'm working from is set up with multiple access levels, user(public), userAdmin(customer) and admin(me), and is built in suck a way that I can generate a new site from the admin portal. I then just need to upload new templates/css/js/images and the whole new site is created.

So theoretically it may be more work to have to separate out the ecommerce databases than it would be to leave it in one.

Hence the question, if there is likely to be issues with having multiple sites in one DB I'll split it out, but if it's not going to make too much odds I'll leave it as is...

In fact I think I just answered my own question, I'll implement it into the existing codebase and set it up to run on one db, with the knowledge that i can always install the whole codebase on another b开发者_StackOverflow社区ox and run a single site on it if I need to :)

Thanks for the quick reply

Having everything piled into a single DB is going to complicate your code considerably. Instead of it being a configuration difference (which DB to connect to), you're going to be peppering your code with filters based on the current customer. I would vote for separate DBs in a heartbeat. Even if you wind up with excessive load from all the small DBs, it should be easy to add a new DB server and point new sites to the DB on the new server.

I can't see the complications this would create in your code being worth it in the long run.