One database for two websites

[ideasco]

I have a live working Zencart site and would like to have a sandbox site that uses the same database. can that be done? If so, I would appreciate any guidelines on how to implement it. thanks

[afo]

No, it can't be done. Any changes you make to the database in test (selecting a new template, adding categories/products, etc) will be reflected in the live store.

If you are restricted to one database, you should be able to give your test site's tables a different prefix, which should solve the problem I mentioned above.

[schoolboy]

Mary Ellen is correct...

As a huge number of shop parameters are controlled in the database, having more than one site share a database (while possible) will mean that configurations applied to any one site, will also be applied to all the others using the same database.

So, your "sandbox" changes will also appear in your real store...

By using a different TABLE PREFIX, you can "house" data for a different application in any database.

So, for example, your LIVE STORE may have the tables prefixed by ZEN_ (a common prefix) or may mot have a prefix at all.

You could do a second install of ZC (in a sub folder of your main site) and in the process of installing, ensure that a PREFIX is given to the tables for that second install.

Much better is to create a full CLONE of the site, and have its dbase competely separate. (if your host is generous enought to allow more that one dbase)

[ideasco]

Thank you both for very clear answers :)

[RobotStore]

:-)

Sorry for bumping this old thread, but I'm considering the same thing.

I want to share the product-information between two shops which carry the same items. MultiSite isn't an option, because I don't want to share the carts / customer info etc.

The idea is to create two shops in a single database, using two different table-prefixes, zen1_ and zen2_ and create tables for both stores.

After creating both stores, I'll drop the products tables from the zen2_ database, and make views to the zen1_ tables.

Since views work like tables (with some restrictions) this might actually work :-)

The plan looks almost too simple :) Anyone who tried this? Or anyone who sees any drawbacks?

[afo]

The separate prefixes should work and keep the information separate, but you can't mix and match between them, so store1 will use zen1 and store2 will use zen2.

[RobotStore]

Yeah, but the idea is to share the zen1_products table using a view with the name zen2_products. So there isn;t actually a zen2_products table, but it's a view.

Any problems to be expected?

[schoolboy]

Zencart uses a complex relational database, so there are numerous occasions where data is cross-referenced. Data is drawn from tables and written to other tables during many customer procedures and the ways this is achieved is extremely detailed.

Here's just one challenge you will face, and is the first hurdle you will have to overcome.

What you propose (shared product data across two sites on the same database) will probably require a database with three distinct table prefixes... store-1, store-2, and shared. This is reasonbaly easy to create on a technical level, but the php CODE that manages the operations and functions within zencart will have to be completely re-written in order to accommodate this radical alteration to the database structure. Given that there are several hundred-thousand lines of code, it will be a busy procedure and could take you a good few months to achieve. (We'll ignore the cost as we assume you'll do it all yourself).

It would be easier to start writing zencart from scratch...

[kuroi]

... 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_".

2. In the site pointing to "zen2_", edit the includes/database_tables.php file to change the following line

define('TABLE_PRODUCTS', DB_PREFIX . 'products');

to

define('TABLE_PRODUCTS', 'zen1_products');

This points the products table from site 2 to the products table for site 1.

3. IMPORTANT now do step 2 for all the other product and category-related pages (you could separate them out, but you would really have to know what you're doing).

Things to look out for (gotchas) ...

If you're using mods that introduce different product types or new tables that extend any of the existing product or category tables then you'll need also to update the declarations for those tables which should be in the includes/extra_datafiles folders in the catalog and admin, though sometimes get embedded at the top of the mods main file.

If you're using mods that hard-code the table names (naughty), then you will need to correct this in order for this approach to work.

Be aware that if this doesn't work on your site, it's going to be difficult for us to provide support, since the problem will almost certainly be specific to non-core code being used on your site, that we can't see. However, conversely, we're making very limited changes to a single file, so it would be very easy to reverse.

[RobotStore]

Thanks for the replies... I'll be looking in to that changing of the defines...

Although I still feel the most for using views... I can't see how the restrictions on views would affect the shop behaviour:

* It is not possible to create an index on a view.
* Indexes can be used for views processed using the merge algorithm. However, a view that is processed with the temptable algorithm is unable to take advantage of indexes on its underlying tables (although indexes can be used during generation of the temporary tables).

Subqueries cannot be used in the FROM clause of a view.

If the view thing works, no lines of code, even no defines, have to be changed...