Try using ER modelling and relational mapping. It's the easiest and fastest methodology I've found for relational db design.
The solutions you proposed would/could work - the problem comes with extensibility of design. If you were to ever try to extend your db, or even change the nature of the relationships between the entities (ie your makes, models, and variants) you could run into trouble.
A (relational?) solution to your problem could be:
create table carMakes(
create table carModels(
create table carVariants(
create table makeModel (
create table modelVariant (
All fields are keys - the last two tables have composite keys, using both fields).
That solution assumes that you're going to be able to use a char20 to uniquely identify all makes/models/variants. If this is not ALWAYS going to be the case, you'd be better of having an incrementing autonumber to be the identifying col in each table, with a "description" field or similar for your textual description. You can then query on the autonumber, but display the text description. As you'd be querying on an incrementing number, efficiency may be increased. Also depending on the size of your db, this method may lead to less redundancy - you would store the autonumbers on the "relationship" tables rather than a larger descriptive field doing the same job.
Also, depending on the nature of your data, you may have been better off having one relationship table (in addition to the three "entity" tables) than two I had above (for eg, with nums rather than char - excuse syntax):
create table makeModelVariant (
Your query for carMakes would then be simple (using the first table solution):
The user selects a car make, 'abc'. Generate a list of models:
The user selects a car model, 'xyz'. Generate a list of variants:
Distinct wouldn't be necessary in the queries as the fields would have to be distinct....