DB table structure

[Havouza]

I have had some interest in the db structure to be able to manipulate prices directly in the tables. I soon found out that it is not so easy. If you add a product somehow through the BO this product is created in 2 tables. Tbproduct and tbproductshop. These are almost identical the shop variation has a column for shop id. Now I wanted to base create a selling price by multiply the wholesale price by 1.5. If I do it in the db using SQL I must do it in the productshop table, otherwise, it has no effect, But if I manipulate the wholesale price in the same table it does not show in BO. BO read the wholesale price from the product table and the selling price from the product_shop table. Why it is so is perhaps how it is done in a multi-shop setup. For me, with single shops, it make no sense

[Traumflug]

AFAIK, database structures make no distinction between monoshop and multishop. A monoshop is a multishop with just one shop defined. And a flag for visually removing all the multishop checkboxes and menus in backoffice at page render time.

[Havouza]

There is a db structure difference. The second product db would not be necessary if the multi possibility was not there. or the code to automatically copy from one table to another when products are added

[Traumflug]

Necessary or not, it's done this way.

[Havouza]

There is a LOT strange in PS, just one of them

[gwasch]

2 tables are not very good. Agree to that. Maybe this should be fixed in one of the next versions of tb

[wakabayashi]

Tbproduct and tbproduct_shop this fact makes me crazy as well. @mdekker do you know why this is needed?

[Traumflug]

I face the same issue with my effort to move shop configuration out of the database, into a regular file (https://forum.thirtybees.com/topic/76/safe-maintenance-strategy-shop-cloning/9): for multishop, URLs & Co. are stored in table 'shop_url', while for monoshops, the same data is stored in table 'configuration'. Additionally, both can be overrided with query and/or environment variables (AFAIK).

I guess three reasons for this data and code duplication:

• Ease of development. Substantial changes to the infrastructure in projects as complex as PS/TB come with a LOT of work. And users barely honor this, because they don't see it. Attempts like the one discussed here are an exception.

• Removing stuff easily breaks things. After doing so, one has to try and test all the millions of combinations of functionality. monoshop/multishop, nonolanguage/multilanguage, distinct themes, all the varieties of products, and so on.

• Backwards compatibility. Removing the older structure means to break all the modules relying on it. Broken modules mean angry customers ("suddenly my module stopped working, but I paid it!") and disappointed developers ("Argh, I have to rework my cash-cow yet again!").

Perhaps that's the reason why PS decided to entirely start over with some parts of the software, like disallowing overrides at all or moving database access to Doctrine. And you're all aware of the results: LOTs of flaming towards PS 1.7.

[Havouza]

I hope that TB 2.0 make most of this history. It will break backward compatibility but at least the users will be aware and hopefully a part of the process. Windows has suffered from the backward compatibility guarantee for many many years