If I were you, I would definitely include a country_id column. You could
use an auto_increment field if your database server supports them, or
you could use the ISO two-letter country codes such as PL for Poland
and US for the United States.

The names of countries *can* change. Look at Zaire, which has also been
called the Democratic Republic of Congo in the recent past. Do you really
want the hassle of changing a foreign key in all of your other tables
when the name of a country is changed on the whim of its politicians?

If you include a country_id column in your country names table, then it
will remain constant despite changes to the country name.

David Harper
Cambridge, England

If your using the countries in other tables, using a numeric key field,
makes it much easier, and more compact to store.  Some country names are
 quite long, for example: The Peoples Democratic Republic of China.
Country names can also change, particularily if the country is a colony
of another country, and then becomes independant.  Changing 47 tables
with country names can be a pain in the donkey.  Storing a 4 byte long
integer is much more compact then storing a 50 character country name,
especially if using 3 or 4 byte Unicode.

I suggest you actually do something like this:

create table (
country_id     integer,     -- autoinc key
iso_code    char(2),    -- 2 letter country code
name        varchar(50));    -- country name

This makes data entry easier, in that if someone is entering data into a
program, they can simply key the ISO two letter codes, rather then
selecting a country name from a drop down list.  Some reports do not
require the whole country name, so you can again use the well documented
 ISO codes there as well.

Paul

In addition to the other responses I would like to add that country names
are language-dependent. Use the ISO codes...

Silvio Bierman

It's much more efficient to store the int as a foreign key than a much
more lengthy varchar