Typically, this third table is used to crate many-to-many relationships, and you usually want to add more "relationship" data into this table, such as the date when the relationship was established, and perhaps WHO did it.

In your case, it seems like a particular car can have only ONE size (one-to-one from the car's perspective) , so it makes sense to add the sizeid into the cars table (as a foreign key).

Now, if you introduce a MANUFACTURERS table with "Toyota", "Honda", "Ford" etc, you will need to add a manuf-id into the cars table (another one-to-one from the cars point of view). Now you can do a somewhat more complex query, to determine what sizes a particular manufacturer makes.

Have fun !

actually if you don't mind, I was wondering if the third table was actually a list of unique cars (so no repeats) then it would be a one to many relationship. I think I understand I would define a new relationship table for many-to-many relationship, but if it's one to many relationship and "size" is an attribute of "cars" then maybe "idSize" should be inserted back into table, "Cars"? Sorry if that is confusing.

I'm not sure what your Cars table represents but this code updates the Cars table with idSize from a text file by matching idCars.

#!perl
use strict;
use DBI;
my $dbh = dbh(); # connect

my $sql = 'UPDATE cars SET Size = ?
           WHERE idCars = ?';
my $sth = $dbh->prepare($sql);

# update
while (<DATA>){  # or filehandle
  chomp;
  my ($idCars,$idSize)  = split /\s+/,$_;
  $sth->execute($idSize,$idCars);
}

# show result
my $ar = $dbh->selectall_arrayref('SELECT idCars,Car,Size FROM Cars');
printf "%5s %-15s %5s\n",@$_ for @$ar;

# connect
sub dbh{
  my $database = "database"; my $user = "user"; my $pw = "password";
  my $dsn = "dbi:mysql:$database:localhost:3306"; 
  my $dbh = DBI->connect($dsn, $user, $pw, 
   { RaiseError=>1, AutoCommit=>1 } );
  return $dbh;
} 

__DATA__
1  1
2  2
3  3
4  3
[download]

poj

It looks like you want to get the hang of many-to-many relationships.

This would occur, if , in your example, the same model CAR was available in many "Sizes" - i.e. perhaps Compact, Sedan, and hatchback.

Now, if you wanted to keep the database "normalized" - i.e. have no duplicate primary data, you would set up CARS and SIZES as you started with, and add a table, say "MODEL", which contained a carID and a SizeID, and perhaps a date-introduced.

Now, for each car, say MiniCooper, you add a record in "MODEL" for each size it offers.

Actually creating a database would make this more clear.

Anyway - all this stuff is old-school "relational" database" modelling.
"NOSQL" databases are in fashion now, and these store key-value pairs. However, it does help to understand the old structured databases, even if you use one of these new-fangled things(My favourite is ElasticSearch).

        "I can cast out either one of your demons, but not both of them." -- the XORcist

ah thank you! I think I'm getting teh hang of it!