Architecture of the car configurator base?

Question

Database design

Good people.
Probably, many have seen car configurators for models, trim levels, options and other car parameters from which you can assemble the desired model configuration and find out its cost.
At the moment, I am faced with the question of the possible development of such a miracle of engineering, and I just can’t figure out the database architecture of such a configurator. Basically, the problem is in a bunch of mandatory and mutually exclusive car options.
Can someone worked with similar things and the exemplary architecture of a DB was saved?
Thanks in advance for your replies...

Answer 1

options
option_id INT NOT NULL
option_name VARCHAR(200) NOT NULL
option_description TEXT NOT NULL
option_required TINYINT NULL
option_collection_id INT NULL
option_collections
option_collection_id INT NOT NULL
option_collection_name VARCHAR(255)
option_linker
option_collection_id INT NOT NULL
option_id INT NOT NULL
option_collections combine mutually exclusive options
in an option_linker and collections
Not?

Answer 2

And if you use a standard VIN code, supplementing it with the necessary criteria such as the price / period of warranty service, because the manufacturer assigns an identification number VIN - Vehicle Identification Number to each auto, motorcycle and vehicle. In the VIN code, it is specially encrypted by whom, where, and also, in most cases, when and in what configuration the vehicle was released, as well as some other information.
The VIN code consists of 17 characters (numbers and Latin letters). manual MADI on the classification of cars .

Answer 3

No, it's more difficult. It is impossible to push all options in the separate table. Models come across options with the same id, but completely different values, depending on the type of configuration, model, engine