Rank: Member
Joined: 6/24/2004(UTC)
Posts: 10
|
[table height="100%" cellSpacing=0 cellPadding=0 width="100%" border=0]
[tr ][td class=msgThread2 vAlign=top height="100%"]Can you use one common database to run multiple stores each with its own domain(license)?[/td][/tr][/table]
|
|
|
|
|
|
Rank: Member
Joined: 8/1/2007(UTC)
Posts: 310
|
Sure you can. But why would you want to do that? Please be aware that content/configuration of each store is kept in the database. So if you are sharing one database for all your web front end stores, then you are basically ending up with the exact same content and configuration for each store.
Now that I think about it more, it might not be possible without certain modifications because even the store URL and the secure store URL are stored in the database. Well, you can surely hack it not to retrieve such information from the database but I dont get the point. |
Thanks,
Satya
support @ bayquel.net
Work: +1 803 883 3226 |
|
|
|
|
|
Rank: Member
Joined: 3/3/2006(UTC)
Posts: 1,737
|
I can see the value in this. As a manufacturer, I may build a database and see that my products will be represented by 20 resellers on 20 different sites each offering a different payment plan, discounts, offers, shipping, etc. I would keep the products current - cuts their involvement and eliminates errors on their part.
I have been approached on this a few times by website owners and other small producers like me. We just haven't found the right platform for this yet. |
Optimists invent airplanes,
Pessimists buy parachutes. |
|
|
|
|
|
Rank: Member
Joined: 11/6/2003(UTC)
Posts: 1,903
|
Wayne,
We have many clients that run multiple stores from a single DB. There are a lot of options (good and bad) to decide before you get the project going. You can mix and match content between the stores without an issue.
Due to the number of ways there are to do this the cost can vary greatly. |
Noah |
|
|
|
|
|
Rank: Member
Joined: 8/1/2007(UTC)
Posts: 310
|
Mitch,
Well, if its only product sharing (or may be categories too) that you want to achieve, then the best way would be to do this:
1. Have one main store behave as the master for product content (and may be the categories too).
2. Install multiple stores with their own databases respectively.
3. Setup an automatic sync mechanism (no human intervention) to automatically update product content (and may be the category content) from the master database to each of the slave databases. This can be done fairly quickly without a big investment.
The solution I am talking about is not a platform. There are a few shopping carts out there that support multiple front end stores off the same database. There is one guy that I know of who has modified BV so that it can drive multiple front end stores with the same database.
But I feel instead of making huge investments in modifying BV platform to support multiple front ends of the same database, a sync mechanism would be relatively cheap, easy/fast to implement and does not require any internal mods to the BV platform.
What do you guys think? |
Thanks,
Satya
support @ bayquel.net
Work: +1 803 883 3226 |
|
|
|
|
|
Rank: Member
Joined: 6/24/2004(UTC)
Posts: 10
|
Hi Satya:
I like your approach as it doesn't change the core code and would be great for version upgrades.
I see several applications for multiple front ends. Display some categories in one store while displaying different categories in a different store and you are running 2 stores from one backend administration app. Run two stores in two different industries, but with a shared backend. Or run a wholesale only store while also running a retail store. Or for channel branding. One brand geared for women and one for men. One for young, one for old. One site with lots of visuals, one a bare bones only catalog. Brand specific sites, only brand "A" on one site and only brand "B" on another site. The opportunities to target niches goes on and on. And it would be great to administer all sales and customers from one point. Imagine 10 front ends and only one backend.
Thanks,
Wayne G.
|
|
|
|
|
|
Rank: Member
Joined: 3/3/2006(UTC)
Posts: 1,737
|
Satya,
My mind goes "Boingggg!" when even thinking about getting my db and other's stores from other store solutions to co-ordinate their effort, not only with my db, but 15 other's stores also. Jeeezus.... there are threads here asking for help in just moving from BVC4 and SF6 to BVC5! Imagine the fun when a dozen other schemes are thrown together!!!! The 'everyone's got to get BVC5 to make this simple' ship has sailed (I was the test case), and hiring someone who's really, really good at db management to tame this dragon isn't likely to happen again. The point is (was) to keep it simple.
Of the 15 or so manufacturers, I've got by far the most complicated product builds and also launched last due to SP2's late and shaky birth. I stuck it out, the others didn't and went elsewhere. If things slow down this summer, perhaps the group can get back to the project, but I kinda doubt it. |
Optimists invent airplanes,
Pessimists buy parachutes. |
|
|
|
|
|
Rank: Member
Joined: 8/1/2007(UTC)
Posts: 310
|
Mitch,
My solution is based on the assumption that all web front ends have the same version of BV running including SP/hotfixes.
If this is the case, then pushing data is not a big deal at all. Also note that you dont need other stores to co-ordinate at all. Since you are the master, you will push information to the sales. the complications you are talking applies while pulling information from a master. I am not suggesting that.
If you are looking at coordinating your data with other store solutions, then you are not looking at multiple front ends based off the same database. Because that only applies to one software (which is BV). If you are looking for sharing data with other store solutions like SF, etc, then yes you will need to write connectors for each different store platform and have them pull over the data. I agree that can get messy and complicated with newer hotfixes, etc. I dont think this is likely going to happen.
But wayne's post was about accomodating for multiple front ends of one BV front end. :-) I will probably implement it on a test store and see how it turns out. Its really interesting. |
Thanks,
Satya
support @ bayquel.net
Work: +1 803 883 3226 |
|
|
|
|
|
Rank: Member
Joined: 6/24/2004(UTC)
Posts: 10
|
Hi Satya:
I will be very interested in your progress. I think your solution is "spot on" and is in exactly the reference I meant for my query. Once the DB connector is implemented the administration of 10 stores is as easy as administering 1 store. And yes, I was referencing all stores being the same version of BV, not multiple solutions. Structure and style the multiple front ends to all work as slaves from one backend. True multiplication of effort. Work once, collect many.
Thanks,
Wayne G.
|
|
|
|
|
|
Rank: Member
Joined: 8/1/2007(UTC)
Posts: 310
|
Thanks Wayne. I will keep you posted. Shoot me an email so that I can follow up with you at a later date. |
Thanks,
Satya
support @ bayquel.net
Work: +1 803 883 3226 |
|
|
|
|
|
Rank: Member
Joined: 11/6/2003(UTC)
Posts: 1,903
|
It all comes down to how "granular" you want the data.
We have clients that share only product data with the child stores (this is a simple scheduled service). Some share Cat and product data. Some have all unique product/cat/desc/prices/shipping etc. The ladder is huge for SEO control. So it can be a "leave the code base alone" solution with little granular control, to a full customization that allows for full granular control.
This has already been done in BVC2004 as well as BVC5. So again it depends on what is needed to understand the scope (price/time/etc.) involved. |
Noah |
|
|
|
|
|
Rank: Member
Joined: 8/1/2007(UTC)
Posts: 310
|
Noah is right. It depends on what amount of control you want. The better the control the more changes are required to the underlying code base. |
Thanks,
Satya
support @ bayquel.net
Work: +1 803 883 3226 |
|
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.