Multiple nopCommerce sites on 1 database

Are each store actually maintained by the same client/merchant? Or are these independent merchants?

To me, the automatic inclination is that a customer registers with a store...... BUT in the case where 1 merchant has 3 stores when a customer registers with 1 store, they can log into other stores.

This may give some weight behind the idea of client/merchant being the key in nop, rather than site... but I am sure different people have different proposals.

If each store is run by independent merchants, then why should registering on one store, give you access to others?

Well it is just the duplication of data that is bugging me....when you normally go through normalization of the data you will illiminate the duplication of this data.

also to be specific.

One program and one DB
each store controlled by his own merchant....
but the merchants resides in the same town. which means customers are local to the stores. chance of repeated customers info more than 80%

I would not want bank A to share my Personal Data with bank B.

In the same vein, I would not want Merchant A to share my data with merchant B

But I may want store A to share my data with store B, if store B was owned by the same merchant as store A.

I would see 2 seperate merchants requiring different databases, as they are 2 distinct applications.

Ownership of stores/sites is a common thought in my thinking!!!!

Bklooste ... you got me confused....is it one DB or more?

It is ecommerce site.. I want to explain more... what I am hoping is to host something like 100-200 sites.. so it will be very demanding to update the programs or fix errors, as I will spend more time deploying stupid fixes than actually adding more functionality or getting new merchantes to sign with me  (more money)...
So I decided that I should go with a centralized program to manage all the sites.. so once update is needed.
But now come the good part for the DB there are several ways of doing this....two I can think off.
1) Use my own server, get a copy of SQL Server (expensive option to do..lots of money to spent). And thus one a merchant sign with me I will duplicate the database and create a new connection string for him to use but within the one program method. So when deleting a databse I delete the associated DB and everything is gone.. (expensive method)

2) Just have all the data stored in One DB with one connection string...

For  the ecommerce part I am also still considering my options...
1) I can charge a flat monthly fee
2) I can charge a transaction fee say 0.5% ontop of the payment gateway fee
3) combination of both.

Also the decision of payment gateways will it be store specific (merchant) or I will sign up and allow all merchant to use my certifications (I become the payment gateway kind off).

To be clear.. one store cannot see any of the information of the other stores or anything related.. so it is completly seperated. Only the admin myself can see everything about all stores.
The only thing that worries me... if the database gets hacked ... there will be lots of info in there. Customer accounts, store accounts....


The more I think about this the more complex it becomes

Right, armed with that information.... this is my take.

You state 100-200 sites..... I will assume 1 merchant/client  owns 1 site, easier to argue.

By using 1 database you will need to have 2 key tables within the system. a) merchant/client and b) site/store

The relationship between merchant/client and site/store is 1:m ; 1 merchant can have many sites (see my previous example on printer cartridges)

I believe product data should be keyed by merchant/client. A site/store is presentation, when the administrator assigns what products (actually categories) appear in each particular store.

To me there needs to be storecategory link table as there can be a m:m relationship

Customers should probably be keyed by client/merchant. The site can be found out through the relationship between merchant/client and site/store

You asked a question about normalization. While in the 70s, 80s, & 90s normalization were hard and fast laws not to be broken, it appears this day that in the more pragmatic world of continuous integration, agile methodologies, Normalization is a guideline, rather than a law...... I see my old database lecturer standing over me, berating me as I speak.

I think with the type of system i refer to here, there will be some duplication of data... it would appear unavoidable.


I agree that the whole purpose of this type of system is to minimize releasing software. If you had seperate databases with presumably seperate installed wwwroots for each store/merchant then if you make a bug fix in a site for merchant 1, then you will have ripple that change out to all other sites. Labour intensive and prone to error, potentially leaving egg on the face of the developer/engineer doing the work.


I guess its important to draw this distinction. in nop as it currently stands the store/site administrator is treated as a special customer. Now from one point of view yes I see this.... the merchant is a customer to the person doing the implementation of the store... but in the problem domain and there interactions between other entities in the problem domain, this entity is not a customer, but a merchant/client of the hence I believe a requirement for the table I am advocating.

The bigger question here is how well SQL server scales for the this type of scenario. I have my concerns, and requires that indexing is done correctly, and then I still have my concerns that it still will scale. Downtime will lead to all your customers complaining, where if you had 100 stores on 1 database instance, and another 100 stores on another instance would only lead to 100 complaints. I would also consider looking at breaking the dependcy on using SQL Server 2005 and using the FILESTREAM type in 2008. This allows you to store images in the database rather than on the filesystem (re- they are actually stored on the file system by SQL Server, but by using this you get the beneefits of SQL Server Transactional Co-ordination). Previously storing images on the filesystem and holding a reference in the database led to 2 operations where you had no transactional coordination and thus you could find yourself in the situation where you had a reference in the database but no image on the filesystem (because it failed to write for some reason) or converse.

But if you had a seperate DB per client/merchant then you get the benefit of more room for customizations.


On your charging structure, ask yourself this. If you rented retail space on the high street (in the US substitute with mall) would you expect to be charged rent at a percentage of shop turnover, or would you expect to rent retail space at a fixed price every month. The answer is the latter. Why then do people in the IT world consider the percentage of turnover or percentage of sale value (transaction).

Just my thoughts..... sorry for the war & peace response.

I won't hog any more bandwidth on this subject. I said my piece...... time for other people to have their say.

bk.... could you explain the legal reasons for me.... I am not aware of any legislation in UK to force the seperation of data into seperate databases.

mkeay ... I agree with you  specially that the user and the store managers are completly unaware of the joined DB.  Also no one store can access another store data (customers, products, categories, emails, the lot).
If I am a web hosting company administrator I have access to all the databases and the websites that I am hosting... which I am providing a computer that I am leasing space an my harddisk as well as allow them to share my programs that I bought with my money.

So in this case having one DB to host all the information of the stores and the customers is infact the same thing. As long as I am able to seperate the information and protect them.


So Airlines sharing each other customer information is also illigal.... My airline once screwed up just befor christmas... I was in the airport, and they said I got overbooked...so they booked me on another airline using the same terminal... Was that illigal....because they shared information!!

Unless hosting companies are breaking the law too!!!!

Interesting! - Im looking at implementing a store with two different front ends but the same Catalogue (Trade and Retail - possibly with either differnet prices for trade or not showing prices for trade thats TBC atm) which is along the same lines as multiple stores in one database (sort of) I was wondering if anyone had any tips on how to modify the code in such a way as to avoid having to re-apply any code changes if a later release needs to be installed.

In my case the store would be hosted on two different domains, say www.abc.com and www.xyz.com I found that in NopSolutions.NopCommerce.Web.OnPreInit() the line of code which gets the theme is

SettingManager.GetSettingValue("Display.PublicStoreTheme");

My thought here is to add in the parameters Display.PublicStoreTheme.www,abc.com and Display.PublicStoreTheme.www.xyz.com iwith a corresponding theme name like RetailStore & TradeStore into the database resource table and then modify the calling code to include something like:

SettingManager.GetSettingValue("Display.PublicStoreTheme." + currentURL);

This would do the switching wonderfully (having done a test) in a single line of code which doesn't seem too bad should I need to upgrade to a later version in the future but wondered if there was a "Best Practise" way of achieveing this as Ive no doubt there will be other differences between the shown and hidden data on either front end.

Ive considered using partial classes but then Id still have to mod the base page cs file - I then considered making a new class which derives from NopBasePage and then updating the classes which currently inherit from NopBasePage to inherit from my new class with my new function in but this would mean changes to about 63 different .cs files which again I dont really want to have to do everytime I upgrade the store - Id be very interested in hearing any thoughts/ideas/suggestions!


Cheers,
Luke

Hi' Any progress on this?

My situation: I need a primary store and then branches (with totally different products).

As others have suggested, if you are hosting for companies a shared DB would not be good as there may be some legal issues and if data is inconsistant it will affect all.

But with one company having many stores it is perfect.

As far as I know, the only other OS project that does this is Magento.

I'd like to still develop in .net (not a requirement though), so to do this I would have to go for a closed system like AspDotNetStoreFront.

Some mentioned they were working on this. Is there an status so far?. Will it be possible to join a dev team?

B.R

Christoffer Munck