If you created a table of
Years, then you'd have a
one-to-many relationship between that table and
Cars; Each Car can only have one Year that it was built and that can be any of the values in your Years table. If you wanted, you could add foreign keys to guarantee this relationship.
Actually, at the point that you're adding a brand
new Car, it's possible that the build year
isn't in your table of Years [yet]; how are you going to handle that?
It's questionable whether you'd need a Years table at all; partly because of this maintenance overhead but also because a "year" is just a number; users
could (and frequently do) just type those in. But, if you want a list of them to choose from, then perhaps you can justify it. YMMV.
That said, allowing users to enter years by hand and then using that data in your SQL is Dangerous. The only [easy] way to do this is to build the SQL dynamically and that leaves you open to SQL Injection attacks.
http://xkcd.com/327/
Regards, Phill W.