From: .:RoKsTaR:. on
No I get the one to one, one to many, and many to many relationship. My
question was, does it make data entry more time consuming to have the info
in many tables over one. Needless to say, John clarified it for me and I'll
probably do many tables so I don't have to make changes later on ;)

"Fred" wrote:

> I have not watched Crystals (even through she is an Access teaching goddess)
> but I suspect that you misinterpreded something from it, and, either way, you
> post indicates that you have yet to really understand the important
> foundation items.
>
>
> (The table design that ends up as ) linking tables is to to properly handle
> "one to many" and "many to many" type relationships between the entities that
> you are databasing.
>
> If the entity that you are databasing in your address book is just People
> (i.e not organizations, companies, etc. lists of coins that those people
> own ) chances are that putting all of their info into one table (i.e. not
> separate linked tables) is the best way for you to go.
From: AccessVandal via AccessMonster.com on
In the meantime you also can look at other Data model from another
contributer Barry Williams site here.

http://www.databaseanswers.org/data_models/index.htm

look something under music or student (I guess).

.:RoKsTaR:. wrote:
>No I get the one to one, one to many, and many to many relationship. My
>question was, does it make data entry more time consuming to have the info
>in many tables over one. Needless to say, John clarified it for me and I'll
>probably do many tables so I don't have to make changes later on ;)

--
Please Rate the posting if helps you.

Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200911/1

From: BruceM via AccessMonster.com on
Convenience of data entry depends on how things are set up. There may be one
phone number or there may be several. You could have Phone1, Phone2 etc.
fields in your main table, but you have to guess about the maximum number you
will need, and you are unlikely to guess correctly. With the phone number
information in a related table you need a continuous subform or other
mechanism to display the phone numbers. If you make the subform big enough
to display three records (phone numbers), in some cases there will be empty
fields that take up room on the form, but if there are four or more phone
numbers it is no problem, as you can scroll up or down as needed. There are
other options, such as a phone number subform on a tab page. My point is
about the overall structure, not the details of the interface. If you allow
for unlimited phone numbers you can find a way that makes sense for entering
and displaying the numbers. However, if you allow for three numbers in the
main table there is no good way to add a fourth.

I would keep in mind how often such information needs to be changed. A
somewhat inconvenient data entry approach may be an acceptable trade-off for
a convenient display.

For payment, attendance, and materials there is no reasonable alternative to
related tables. The details depend on considerations such as the
relationship between materials and attendance. If you want to associate
specific material with specific lessons (attendance) you may approach it
differently than if you just want a listing of materials covered or books
purchased or some such.

.:RoKsTaR:. wrote:
>No I get the one to one, one to many, and many to many relationship. My
>question was, does it make data entry more time consuming to have the info
>in many tables over one. Needless to say, John clarified it for me and I'll
>probably do many tables so I don't have to make changes later on ;)
>
>> I have not watched Crystals (even through she is an Access teaching goddess)
>> but I suspect that you misinterpreded something from it, and, either way, you
>[quoted text clipped - 9 lines]
>> own ) chances are that putting all of their info into one table (i.e. not
>> separate linked tables) is the best way for you to go.

--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/Forums.aspx/access-tablesdbdesign/200911/1