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  

Best Practice Value list or linked table?



 
 
Thread Tools Display Modes
  #1  
Old November 19th, 2009, 06:56 PM posted to microsoft.public.access.tablesdbdesign
Barry A&P[_2_]
external usenet poster
 
Posts: 119
Default Best Practice Value list or linked table?

I am beginning to wonder if i overcomplicate my database. i am going to add a
field to my T_partnumbers for unit of measure (UOM) and can not decide if i
should do it like i have in the past and use a combo (on my forms of course)
with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
my part numbers table or just use a value list in my combo and save the
actual UOM abbreviation in my P/N table.

What is a good determining factor for which method to use?
And What to store in my table LB, OZ, EA, ect. or their respective ID's?

I feel linked tables for everything is becoming complicated as i view my
T_Partnumbers all of the data is Greek and meaningless unless i query and
join the appropriate tables, Maybe this is the Database method and i am
afraid to further stray from anything humanly recognizable..

Thank you for your thoughts..
Barry
  #2  
Old November 19th, 2009, 08:09 PM posted to microsoft.public.access.tablesdbdesign
Jeff Boyce
external usenet poster
 
Posts: 8,621
Default Best Practice Value list or linked table?

Barry

It sounds as though you are trying to make sense of the raw tables. Stop
now!

Access tables store data. Access forms (and reports) display data (via
queries).

Don't try to make an Access table work like a spreadsheet -- it isn't one.

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

"Barry A&P" wrote in message
...
I am beginning to wonder if i overcomplicate my database. i am going to add
a
field to my T_partnumbers for unit of measure (UOM) and can not decide if
i
should do it like i have in the past and use a combo (on my forms of
course)
with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid
in
my part numbers table or just use a value list in my combo and save the
actual UOM abbreviation in my P/N table.

What is a good determining factor for which method to use?
And What to store in my table LB, OZ, EA, ect. or their respective ID's?

I feel linked tables for everything is becoming complicated as i view my
T_Partnumbers all of the data is Greek and meaningless unless i query and
join the appropriate tables, Maybe this is the Database method and i am
afraid to further stray from anything humanly recognizable..

Thank you for your thoughts..
Barry



  #3  
Old November 19th, 2009, 08:34 PM posted to microsoft.public.access.tablesdbdesign
KARL DEWEY
external usenet poster
 
Posts: 10,767
Default Best Practice Value list or linked table?

A combo can be from a table with only one field and use it bound.

--
Build a little, test a little.


"Barry A&P" wrote:

I am beginning to wonder if i overcomplicate my database. i am going to add a
field to my T_partnumbers for unit of measure (UOM) and can not decide if i
should do it like i have in the past and use a combo (on my forms of course)
with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
my part numbers table or just use a value list in my combo and save the
actual UOM abbreviation in my P/N table.

What is a good determining factor for which method to use?
And What to store in my table LB, OZ, EA, ect. or their respective ID's?

I feel linked tables for everything is becoming complicated as i view my
T_Partnumbers all of the data is Greek and meaningless unless i query and
join the appropriate tables, Maybe this is the Database method and i am
afraid to further stray from anything humanly recognizable..

Thank you for your thoughts..
Barry

  #4  
Old November 21st, 2009, 12:38 AM posted to microsoft.public.access.tablesdbdesign
Armen Stein
external usenet poster
 
Posts: 507
Default Best Practice Value list or linked table?

On Thu, 19 Nov 2009 09:56:05 -0800, Barry A&P
wrote:

I am beginning to wonder if i overcomplicate my database. i am going to add a
field to my T_partnumbers for unit of measure (UOM) and can not decide if i
should do it like i have in the past and use a combo (on my forms of course)
with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
my part numbers table or just use a value list in my combo and save the
actual UOM abbreviation in my P/N table.

What is a good determining factor for which method to use?
And What to store in my table LB, OZ, EA, ect. or their respective ID's?

I feel linked tables for everything is becoming complicated as i view my
T_Partnumbers all of the data is Greek and meaningless unless i query and
join the appropriate tables, Maybe this is the Database method and i am
afraid to further stray from anything humanly recognizable..


Hi Barry,

I suggest avoiding Values Lists entirely. They must be maintained
separately from the data itself, so you run the risk of them being
redundant or out of sync.

You can use the lookup table as you describe. If you like, you can
use the abbreviation as the primary key and join with that. Then
you'll be able to see the abbreviation without the joining table.

Another example of this is a StateProvince table. If you know the
abbreviations will be unique, you can use them for the primary key
instead of an autonumber.

But I agree with other posters that you shouldn't be looking at your
tables directly to see what's in them. All your related information
should be joined in from other tables using queries, forms or reports.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

  #5  
Old November 24th, 2009, 08:07 AM posted to microsoft.public.access.tablesdbdesign
Barry A&P[_2_]
external usenet poster
 
Posts: 119
Default Best Practice Value list or linked table?

Thank You Armen



"Armen Stein" wrote:

On Thu, 19 Nov 2009 09:56:05 -0800, Barry A&P
wrote:

I am beginning to wonder if i overcomplicate my database. i am going to add a
field to my T_partnumbers for unit of measure (UOM) and can not decide if i
should do it like i have in the past and use a combo (on my forms of course)
with a row source to a T_UOM with Ea, LB, OZ, Ft Ect. and store the UOMid in
my part numbers table or just use a value list in my combo and save the
actual UOM abbreviation in my P/N table.

What is a good determining factor for which method to use?
And What to store in my table LB, OZ, EA, ect. or their respective ID's?

I feel linked tables for everything is becoming complicated as i view my
T_Partnumbers all of the data is Greek and meaningless unless i query and
join the appropriate tables, Maybe this is the Database method and i am
afraid to further stray from anything humanly recognizable..


Hi Barry,

I suggest avoiding Values Lists entirely. They must be maintained
separately from the data itself, so you run the risk of them being
redundant or out of sync.

You can use the lookup table as you describe. If you like, you can
use the abbreviation as the primary key and join with that. Then
you'll be able to see the abbreviation without the joining table.

Another example of this is a StateProvince table. If you know the
abbreviations will be unique, you can use them for the primary key
instead of an autonumber.

But I agree with other posters that you shouldn't be looking at your
tables directly to see what's in them. All your related information
should be joined in from other tables using queries, forms or reports.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

.

 




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 11:27 AM.


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