Country info database

Hi,
Fairly new to this so hoping someone can stop me wasting time going down the wrong road.
Trying to produce a table of country info, (several columns - country, remarks, useful websites, last updated source), etc. Which is easy.

Then othe tables consisting of approx twenty different subjects (finance, company info) with several columns (e.g. available Yes or No, info, websites etc) for every country.

My idea was to create a main table (the country info) and give each country a sub-data sheet containing each of th twenty 'product types (and their associated columns). Even though most product types will not be availablee this is iintended to ensure consistency should the availability change down the line.

Does this structure make sense to anyone?

Thanks,

"=?Utf-8?B?Q0FybA==?=" wrote in
:

My idea was to create a main table (the country info) and give each
country a sub-data sheet containing each of th twenty 'product types
(and their associated columns). Even though most product types will
not be available this is intended to ensure consistency should the
availability change down the line.

It is not very clear from your post what exactly you are planning to
achieve, but this solution is probably not the best way to go. For a start,
"subdatasheets" do not have any place in normal db design -- all data entry
should use proper forms rather than the table grids.

From the information in your posting, it seems you need (at least) three
tables -- Countries, Websites, and Subjects. It is quite likely that you
will need more tables to implement the relationships between them. You have
also mentioned Products and ProductTypes but I cannot really help without
knowing more about what you are trying to model.

B Wishes



Tim F

On Tue, 8 Jun 2004 07:36:13 -0700, "CArl"
wrote:

My idea was to create a main table (the country info) and give each country a sub-data sheet containing each of th twenty 'product types (and their associated columns). Even though most product types will not be availablee this is iintended to ensure consistency should the availability change down the line.

Does this structure make sense to anyone?

First off - I'd recommend NEVER using datasheets for routine
interaction with your data. Use Forms instead.

Secondly, it appears that you have a classic many to many
relationship. This needs *three* tables: Countries; Products; and a
ProductsSold table linking them. This "resolver" table would contain
the CountryID and the ProductID as links to the other two tables, plus
whatever fields you need to cover this product in this country.


John W. Vinson[MVP]
Come for live chats every Tuesday and Thursday
http://go.compuserve.com/msdevapps?loc=us&access=public

"CArl" wrote:

Hi,
Fairly new to this so hoping someone can stop me wasting time going down the wrong road.
Trying to produce a table of country info, (several columns - country, remarks, useful websites, last updated source), etc. Which is easy.

Then othe tables consisting of approx twenty different subjects (finance, company info) with several columns (e.g. available Yes or No, info, websites etc) for every country.

My idea was to create a main table (the country info) and give each country a sub-data sheet containing each of th twenty 'product types (and their associated columns). Even though most product types will not be availablee this is iintended to ensure consistency should the availability change down the line.

Does this structure make sense to anyone?

Thanks,

Carl

Based on your description, I'd suggest you look into the topic of
normalization. Then, shut down your PC and grab paper/pencil and start
laying out relational tables.

If this doesn't make sense, here's a pointer --

If one country can have many "useful websites", you have described a need
for two tables, related one-to-many.


--
Good luck

Jeff Boyce
Access MVP