Split database into two parts

Hi,

I want to split the database into two parts:

- Shop data
- Products database

I'd lilke to receive some advise. ¿Would this have a considerable impact into the nopCommerce architecture?

I still don't know very well its architecture, but I see it uses an Entity Framework based Data Access Layer, so it shouldn't be very difficult to split the database each entity is accessing, ¿isn't it?

My idea is to implement multishop in a easy way: different web apps in IIS (one for each shop), each of them accessing its own database, but all them with a common Products database.

This image illustrates the idea:

http://yfrog.com/mtcapturaep

¿What do you think?

I wouldn't do it with v1.8 wait for 1.9

I still wouldn't do it. Use 3 databases and sync your data. Seems easier to do and to upgrade.

Hi,

The reason I want to do it is because nopCommerce does not support multisite, and there is not release date for that. I have more than 100 eCommerce shops I'd like to migrate to nopCommerce, but I can't if each has its own database, that would take a lot of resources.

Have in mind that my database contains more than 30.000 products... the sync of 100 shops (and growing) * 30.000 means a lot of wasted resources...

Bear in mind I have not tried what I'm about to suggest, however from what I understand SQL Server will treat synonyms the same way as tables.

What you could do is have one master database, then define a synonym on the other databases for tables like Nop_Product, Nop_ProductVariant, etc..

In theory that should work, however I haven't tried it and don't really know if synonyms work like that.  There's also potential problems where people could potentially update the same item at the same time, however that could be mitigated by limiting updates only to your master site and disable product management on all child sites.

So you would need to split off all tables related to products into its own database like Nop_Product, Nop_ProductVariant, Nop_ProductPicture, Nop_Category, Nop_ProductCategoryMapping, etc, etc.

So you would call that your "Product" database.

Then your other challenge would be the Nop_Customer and Nop_Order tables. Nop_Order references both Nop_Customer and Nop_Product. I think this split decision will be the most difficult. Also the Nop_ShoppingCart table will be a challenge because it references Nop_Customer and Nop_Product.

Having a multi-store database is very important because I have many stores that I want to integrate into one database yet keep track of which users are registered to which website.

Let me know what you decide to do.

The other thing I just thought about doing was if you move any product pictures to being stored on the filesystem rather than the database, the rest of the data really is not that significant space wise.  You could then use triggers , sprocs, and a queueing system to propagate changes from one database to the others.

As before, I'd have one store or database be the master and disable product management on the child databases, that way you never need to worry about handling update conflicts if products happen to be updated at the same time.