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 box and run a single site on it if I need to :)
Thanks for the quick reply