Multiple nopCommerce sites on 1 database

Im teaching myself about SQL  as I go, so please bare with me :-)

I have two stores that I'm trying to get run on one DB, this is what Ive done so far.

I duplicated the file structure on

www.123.com
and placed it at
www.ABC.com

This works but but the problems I have found is the front end of the stores share Names & INFO-BLOCK topics.

Ive been able to use <iframe> to help customize the front page, but I still have the issue with site names and other identifying characteristics.

my thoughts were, to duplicate and rename the tables in the DB where the site keeps its 'identifying characteristics'


Example,  www.123.com
The front page values and content. Instead of going to table nopcommerce.frontpage it will be directed to mopcommerce.frontpage123   but for content like catalog & customer base it still comes from the same pool.

I hope that makes since, to me this would be easy if I know where in NOPCOMMERCE code it points to the specific table.

You are going to need to change the code of the website and the sql.  This is no more small task.

anyone have insight on where a good place to start ?

Think about what do you need separated in your shop.
Suggestions:
Settings (Shop name, url, theme...)
Products and Categories
Customers
Payment Methods & their settings
Shipping Methods & settings

For each of these you have to make another table (maybe with a prefix to the original name) with same columns as the original.
Make new set of Stored Procedures for these tables.
Change SqlTABLEProvider where TABLE is the table you are changing, ie. SqlSettingProvider. The new ones will call the new stored procedures.

That's about it. There will probably be some issues with this approach, but probably nothing big.

Hope this helps.

The common thing in this topic is the diversity of requirements for sites and data.

There isn't a simple 'one-size-fits-all' solution to this. As someone said way back in the topic, planning is the key. Some RP and a logical analysis of factors such as cost, time, future requirements and cost of ownership will probably give you the solution for your problem? I guess this continues the ethos of OS stuff generally and NOP specifically in this context, in that it does most of the common things well and is a good enough boilerplate for all those wierd and wonderful things people need to add.

I've done a number of NOP based sites. These have included 20 single brand european retailer sites, all independent, locally managed by partners. The decision here was seperate DBs. Why? Well, time and cost. Ideally I'd have implemented some central data and code base [as others on here have mentioned] that managed it all (localisation, currencies, tiered pricing, master content management, local content management, order processing, delivery, individual payment gateways, the list goes on) but I had 6 weeks and no budget so essentially one site got developed, then rolled out 20 times.

The task of centrally managing this is going to be huge, but as is often the case, businesses can be shortsighted and see up front costs [as costs, not investment is business], ignoring the cost of ownership or plain and simple just don't have the money now, but some pretty healthy projections so will worry about it later. Anyway, I digress.

I shall hopefully be doing a dual site project in the next few weeks, and I intent to run this from a single DB, but it will be running different skins and layouts, so [and this is a significant point based on my experience developing e-commerce solutions generally] it will be running 2 sites in IIS as the templating and presentation logic will be significantly different.

Running multiple sites from one DB and codebase as a SAAS style operation means that you'll get 100 sites that all look the same. There is a limit to what you can do with skins and inevitable the customer will want something different that suddenly everybody gets.

Maintaining multiple versions of the code is easier if you stick to the structure of the application with projects in a solution as nop does already, so multiple 'sites' is less of an issue. I would also like the idea of managing IIS with individual application pools and permissions such as write/modify etc at the per domain level.

If you are 'selling' an ecommerce platform, some clients will require some level of individuality so if they do it themselves it just dissolves in to a hosting DIY service. If you are doing the job of skinning the site for them, it's always going to be easier to do a single install of code and db that you can customise.

The point I'm making here is, that whilst it is fairly easy to have a single codebase and db for multiple sites, the ability to design and present information without restriction or limitation [and this is the great thing about nop etc] is broken and becomes less useful to brand sensetive consumers.

So you could get round this by adding a presentation layer engine like Umbraco [see you in about 2018] that each account could use for templates and layout elements, but this is now just madness.  

From a database perspective, it's possible [if a little extreme] to have a database for general application and account management and multiple databases for 'localised' data such as products and registrations. This would work ok. Each account could be backed up independantly, manage their users and products in isolation and would be less significant if compromised.

A cat skinning exercise indeed :)

Sorry, Ed, but I have to disagree with you in some points.
First of all, separate skinning is not a problem at all once you implement separate settings for each of the sites, since active theme is stored in the settings.
In my company we have already implemented the multisite functionality. I think you are looking a bit too complicated at the subject. Our solution is similar to Magento multisite solution, just without multiple levels of separation.

There is one thing that you have to consider though, and that is updates. Some code changes could have not been implemented as clean modules, so there are some changes to original nopCommerce code that we had to make. These changes have to be made after each update. With all other changes that we made it takes about half a day to update the nopCommerce to newer version at this point.

If someone is interested in purchasing the multisite functionality, I could talk with my boss about it. However I am not sure if it is even possible, since we are not official nopCommerce partner.

Good Day!



I read this thread a few months back and am wondering where this stands?


I’d like to show you what we do and get some thoughts from you all

We sell unclaimed and damaged freight in multiple physical and virtual
In the real world we have two retail stores and a weekly bid sale, a weekly tech sale, and a wholesale venue


In the virtual world we have:

http://www.cargolargo.com/
http://stores.ebay.com/cargolargo__W0QQ_sacatZcargolargoQQ_sidZ16951081QQ_stickyZ1QQ_trksidZp4634Q2ec0Q2em14?_sop=1&_sc=1
http://stores.ebay.com/cargolargorex
http://www.amazon.com/shops/ASXQJI4Q3U14A
http://www.amazon.com/shops/cargolargo
http://kansascity.craigslist.org/search/sss?query=CARGO-LARGO%21%21&minAsk=min&maxAsk=max
http://www.cargolargosales.com/Catalog.aspx
http://apps.facebook.com/discovershopwin
http://www.facebook.com/pages/Independence-MO/cargo-largo-fan-page/110402245645712?ref=ts

so you see we have:
1 company
3 facilities
11 warehouses
Every warehouse works in a bubble and has no control over product in other warehouses

So I don’t mind if they see the others product, but users should only be able to manipulate product in their own warehouse.

So yes..... install NopCommerce several times – ok that’s one solution…
But I would also like customers to have a single sign-on
And have sales reporting as one conglomerate

I have one warehouse (wholesale) set up now:
http://dev.cargolargo.com/sales/Category/53-buy-in-bulk.aspx

Any Ideas?

Thanks in advance!


jack hammes
cargo largo
system analyst
(530) 330-JACK GoogleVoice 24/7
(816) 350-6213 Office
(816) 753-4300 Text/cell
[email protected]
http://www.cargolargo.com

msargius wrote:

Hi msargius

In view of all these legal-financial implications, I suggest one site- multiple stores (1:m) and one store- one database i.e. 1:1.

What do you say ? What will be required changes in the website code and the complexity level of this change since v1.8 uses entity framework..?

Hi,

I am building a "Virtual Mall".  I am looking for a person or group that can develop the following:

1) Main website with "Virtual Mall" content and various "storefront" and "category" searches.

2) One Database to hold all of the storefronts.

3) Each storefront will have it's own look and feel.

4) Each storefront will have it's own dashboard.  This dashboard will not be able to modify the main site.  The dashboard will only work on the storefront.

5) Each storefront will have it's own products.

6) Storefront creation tool.  A real merchant will register and build their storefront.  A number of business rules will be added to validate their bank accounts for billing, etc.

-Jim

amol_b wrote:



Ok ... I will tell you a senario which is an actual thing that is happening right now with the financial  banks. Orchard Bank and Household Bank....if you have both credit cards from them, and you try to register under the same user name in both banks website it will be rejected as the user is already registered. So what they do is they let you login under different user names. So let say for Orchard bank your user name is USERNAME-1 and Household bank is USERNAME-2. If you  go to www.orchardbank.com and enter the second username it will tell you sorry you are a member of household bank, and they will redirect you. The other way also happens. In order for them to do that, then they share the same DB.

The changes that you need to do will depends on the complixity of what is in your vision... Are you targetting a specific market? Do you just want a lot of domains pointing to the same place for web presence as if different stores are providing the same products different prices ? or do you want to franchise the stores....