Question

[John]

hi Everybody,

I'm just starting with Access and I'm working on a database of movies and am
storing it in a table called tblMovies

One of the field of the database is the language of the movie, whcih can be
one of the following: English, German, Spanish, Italian, Japanese
or French,

My question is would it make sense to start a new table called tblLanguages
and store the language there and then link the table to
the languge field of tblMovies ?

TIA

 

[Rick Brandt]

hi Everybody,

I'm just starting with Access and I'm working on a database of movies
and am storing it in a table called tblMovies

One of the field of the database is the language of the movie, whcih
can be one of the following: English, German, Spanish, Italian,
Japanese or French,

My question is would it make sense to start a new table called
tblLanguages and store the language there and then link the table to
the languge field of tblMovies ?

TIA

Sure. It allows you to use a ComboBox to make the entry rather than typing it
out and lets you control what valid entries are. When the number of choices is
small you can choose to go with a VALUES list instead of a table, but it is
never "incorrect" to use a table.

 

[John]

ok, thanks.

One more question.

I assume that if I make a table of languages I should also include a field
in it that will assing a unique number (AutoNumber ) for each languge and I
will store this number in the master table and let Access look up the
language whenever the information is needed to appear in a form.

Let me know if this is correct way of doing it

TIA

 

[Rick Brandt]

ok, thanks.

One more question.

I assume that if I make a table of languages I should also include a
field in it that will assing a unique number (AutoNumber ) for each
languge and I will store this number in the master table and let
Access look up the language whenever the information is needed to
appear in a form.
Let me know if this is correct way of doing it

That is more a question of style and preference than correct/incorrect. For
relatively short text entries that aren't expected to change storing the actual
text in the related tables is fine. In those cases the lookup table is really
just to provide control over what is entered.

While it is true that using a numeric ID field and storing that in related
tables would take fewer bytes, the difference in a case like this would not be a
concern (of mine). Disk space is the last thing I worry about any more.

The advantage of storing the actual text is that there is one less join required
in queries where you need the text value in your output.