A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Database Design
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Design with no experience



 
 
Thread Tools Display Modes
  #11  
Old November 14th, 2009, 07:22 PM posted to microsoft.public.access.tablesdbdesign
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Design with no experience

On Sat, 14 Nov 2009 05:59:01 -0800, .:RoKsTaR:.
wrote:

So I watched crystals video and went through some of the other material and
have been noodling around with the program and existing databases to help
figure things out. In crystals video, she talks about putting people,
addresses, and phone numbers in their own table and linking them by their
unique id or key number. Existing templates do this all in one table, whcih
to me makes data entry easier, but I'm not sure.


One table makes data entry easier... but is also more limited. Some people use
more than one address; many people use more than one phone (home, office,
mobile for example). It's a judgement call based on how the database will be
used - some databases will be fine with one table (with its limitations),
others may need separate tables.

Can anyone clarify if separate tables would make the data entry portion more
time consuming? Can you have one form that enters data into many tables?


Sure. A Form based on Contacts with Subforms based on the Address and Phone
tables. There'll actually be three forms, but they'll all be onscreen and
editable at the same time.

Side note : A friend of mine told me he can get me some training dvds from
his office library, so I think that's my next step


If they're good ones....

--

John W. Vinson [MVP]
  #12  
Old November 17th, 2009, 06:25 AM posted to microsoft.public.access.tablesdbdesign
.:RoKsTaR:.[_2_]
external usenet poster
 
Posts: 39
Default Design with no experience

I talked to him yesterday and he said that he can get me something called
trainsignal from their library. He says it's pretty intense and he thinks
his company used it to certify some employees for access...does that sound
right?
  #13  
Old November 17th, 2009, 07:00 AM posted to microsoft.public.access.tablesdbdesign
.:RoKsTaR:.[_2_]
external usenet poster
 
Posts: 39
Default Design with no experience

He says it something called trainsignal, but didn't know much about it. From
what I can tell, it looks pretty thorough
  #14  
Old November 17th, 2009, 07:33 PM posted to microsoft.public.access.tablesdbdesign
.:RoKsTaR:.[_2_]
external usenet poster
 
Posts: 39
Default Design with no experience

Whoops I dind;t think that first post showed up so I did another
one...sorry
  #15  
Old November 18th, 2009, 02:05 PM posted to microsoft.public.access.tablesdbdesign
Fred
external usenet poster
 
Posts: 1,451
Default Design with no experience

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.
  #16  
Old November 24th, 2009, 12:01 AM posted to microsoft.public.access.tablesdbdesign
.:RoKsTaR:.[_2_]
external usenet poster
 
Posts: 39
Default Design with no experience

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.

  #17  
Old November 24th, 2009, 05:41 AM posted to microsoft.public.access.tablesdbdesign
AccessVandal via AccessMonster.com
external usenet poster
 
Posts: 461
Default Design with no experience

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/For...esign/200911/1

  #18  
Old November 24th, 2009, 03:05 PM posted to microsoft.public.access.tablesdbdesign
BruceM via AccessMonster.com
external usenet poster
 
Posts: 448
Default Design with no experience

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/For...esign/200911/1

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 01:04 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.