29

Deep dive on the Magento internals here, not looking for a solution to a concrete problem, just trying to understand some implementation details.

When you create a Configurable Product in Magento, and then create child Simple Products to implement things like shirt size, color, etc., Magento stores this relationship in two separate tables.

catalog_product_relation
catalog_product_superlink_table

Why are these relationships stored twice?

Is this legacy code, or is there a semantic distinction between a product relation link and a product "superlink" link?

Does the system expect these to be the same, or is it a valid object state to have these tables representing different parent/child relationships?

Alana Storm
  • 164,128
  • 91
  • 395
  • 599
  • 1
    Don't know how it was in 2011, but now the superlink table is called `catalog_product_super_link` – gvlasov Jan 10 '19 at 01:32

1 Answers1

31

Why is great question. The catalog_product_super_link table only contains data related to configurable products. catalog_product_relation also contains the relation information for bundled and grouped products, in addition to the configurable relations.

All the business logic revolving around configurable products refers to the catalog_product_super_*tables, e.g. finding the configurable attributes and price updates for a configurable product.

The catalog_product_relation table in contrast is used by classes not specific to configurable products, like the abstract catalog product indexer classes.

It seems that the Magento core team wanted to separate the logically distinct functionality not only into separate PHP classes, but also into separate database tables. Possible advantages? I guess theoretically it is easier this way to change the configurable product implementation without disrupting the indexer implementation.

This is just a guess - I haven't confirmed that or spoken with someone who "knows" (mental-note-for-imagine)

Vinai
  • 14,162
  • 2
  • 49
  • 69
  • 20
    Everything is more simple. Configurable type of products were developed when there were no relation index. It even was the first composite product type. Of course it had own table at that time. As soon as there were created more composites, the relation table were created to unify logic of retrieving child/parent products for indexes and other features where it is required. – Ivan Chepurnyi Dec 15 '11 at 11:12
  • Ah, that makes a lot of sense! Thanks for clarifying, Ivan. – Vinai Dec 15 '11 at 18:37