Jump to content
thirty bees forum

DB table structure


Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...