How to organize the logic for building a query in the database based on the data received in GET?

Question

PHP

I'm making a product catalog for a store. I decided to immediately set up the CNC (or rather, a clear URL for Yandex and a clear URL for Google, people are unlikely to look at the URL).
Defined the following structure:
/toyota/
/toyota/rav4
/toyota/rav4/body
/toyota/rav4/body/front-bumper
/toyota/rav4/body/front-bumper/SKU
Until the SKU (part number) is received, the script will show subcategories
With mod_rewrite this URL will be passed to the server as catalog.php?make=toyota&model=rav&category=body&subcategory=front_bumper&sku=SKU
The problem is that the CATEGORY and SUBCATEGORY values ​​will not be unique. Accordingly, I cannot search the database for this parameter.
I came up with this option:
if (there is a SKU)
output product
if (there is SUBCATEGORY)
you need to display a list of products.
to do this, you need to find all products with the desired category ID, and for this you need to find all records in the category table with the SUBCATEGORY and MODEL parameters, i.e. Assuming that within one model (RAV4, for example) all product subcategories will be unique, there will not be two "front_bumper" categories.
if (there is a CATEGORY)
//display the list of subcategories, according to the same logic - within the RAV4 model, all product category names are unique, there will not be two "engine" categories.
if (there is MODEL)
// everything is already simple here, all my models are unique, so we just look for the category ID with this model, and then we display a list of subcategories whose parent is the model ID.
But then there is a limit on the number of nested categories, what if I want to make another category? To be /toyota/rav4/body/front/bront_bumper/.
Maybe there is some elegant and popular solution?

Answer 1

Make toyota/rav4/body_12/front_41/...
Where 12 and 41 id categories and subcategories. Pay attention to the url of materials on habré, for example. They do so often.

Answer 2

As an option:
Abandon the concept of subcategory. Leave only the concept of a category that can have a parent category (all in one table, if there is no parent, then parent_id = 0, the hierarchy can be arbitrarily long, an ordinary tree will turn out)
The product will have a binding to the model and category. But I would not do them directly, but through separate tables. This is so as not to produce categories, and the same spare part can be for several models
In the analysis of the URL, the first two fields are the manufacturer model, the last SKU. If there are more than 2 fields and the last one is not a SKU, then it is a category. Ignore the rest