One database for two websites

[kuroi]

If I understand correctly what you're proposing, it would make the store that was relying on views unbelievably slow.

Zen Cart frequently joins lots of tables together and the fields used to construct those joins have been carefully indexed to optimise response times.

To perform those joins on unindexed views would create an enormous performance hit.

[RobotStore]

Well, using the define option might work better then... maybe I'll try both, to see if there's any performance difference... but both solutions use the same approach... 'redirect' the data from one table to another.. :-)

[kuroi]

Well, using the define option might work better then... maybe I'll try both, to see if there's any performance difference... but both solutions use the same approach... 'redirect' the data from one table to another.. :-)

Hmmm. They're not really the same at all. A view isn't a table. It's really the output of a saved query. So the view approach crudely equates to replacing each table in product-related Zen Cart query, with a subquery that needs to be linked by full text comparisons in the absence of any indexing - hence the performance hit.

[frank18]

This is one interesting thread indeed!

... err guys. It can be done, and it doesn't require oodles of re-writing of core.

For example:

1. Create two sites in the same database with different database prefixes, e.g. "zen1_" and "zen2_". .........

kuroi, how would one create two sites in the same database? I'd be very interested in reading the solution to this question.

Thanks / Frank

[schoolboy]

This is one interesting thread indeed!



kuroi, how would one create two sites in the same database? I'd be very interested in reading the solution to this question.

Thanks / Frank

Safest way is to use the standard zencart INSTALL procedure for a new website. Point the install to the SAME database you are using for your existing site

When prompted (during setup), for a database prefix, put the desired prefix into the input field.

[DrByte]

Well, using the define option might work better then... maybe I'll try both, to see if there's any performance difference... but both solutions use the same approach... 'redirect' the data from one table to another.. :-)

They're not really the same.

Plus, in v1.x there is an architectural limitation which requires that you have write privileges ("UPDATE") to the table so stats can be updated every time a visitor visits a product's info page. If you're using a read-only view then you'll encounter SQL errors.
Instead, if you use the prefix approach suggested by kuroi you won't run into that problem.

[kuroi]

@frank18

Schoolboy's approach would work fine, but there are some issues specific to how web hosts configure their hosting accounts that would need to be taken account off too.

For many hosting accounts, database access is treated as integral to the account. It doesn't have to be, but it's understandably convenient for the hosts to manage it thus. Unfortunately, many hosts can only allow you one dedicated IP address per account, and therefore only one dedicated SSL. So even if you have many sites running off one database, you may have to make provision for them to use the same SSL cert when they go live.

You also end up with two sets of code to patch and upgrade. Personally I prefer to run with one set of code and one database. There's the multisite mod for doing this, which is one approach. I use a different one.

The hidden wholesale mod was originally conceived off as a way of running wholesale and retail sites from a single installation. However, my version of it centralised the condition for deciding which products could be used for which site, which makes it incredibly flexible. For example I have a client with a couple of extra fields on the product table to indicate to which site each product belongs (or both). I have another with a dedicated sale site that filters on whether a product has a sale price.

In these cases there is also a tweak to config files to ensure that incoming URL is perpertuated, and an overridden init_templates file to ensure that the right template is used for each variant of the site.

Hope that provides extra food for thought and not indigestion.

[frank18]

@kuroi & schoolboy

so, if I understand that right, using the same account with 2 stores in 2 separate subdomains should work just fine as long as one uses the different prefixes? Have to give this one a go over the weekend on my local machine.

Thanks to all of you - time for beddies