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  

Efficient Table Design Questions



 
 
Thread Tools Display Modes
  #1  
Old February 23rd, 2010, 05:15 PM posted to microsoft.public.access.tablesdbdesign
Monet 138
external usenet poster
 
Posts: 7
Default Efficient Table Design Questions

I'm working on a Project Manager DBase for our engineering department. One
of the things they want to be able to record within each project is the Size,
Length and Material of the pipes installed. They also want to be able to run
reports that would provide them totals based upon region, year, etc.

So I'm looking at sizes ranging from 1/2" to 48" (approx 20 different sizes)
plus a wide range of possible materials for each size.

Question 1:
Since a project could have multiple materials of the same pipe size
installed, do I create a field for each possible size & material combination
paired with its own length field, which would mean approx 100 or more fields.
Or if I estimate that a max of 20 size-material combinations would ever be
needed in a single project, would using a field-set similar to the example
below still work well enough for the totaling reports?

Size_1 | Material_1 | Length_1 | Size_2 | Material_2 | Length_2 |Size_3 | etc.

Anyone have a suggestion for something better than the two options I outlined?

Question 2:
Since the size-material quantities will be unique for each project, is there
any reason to actually seperate this information out into a second table or
should it just be kept within the primary table?

Thanks for the help.

--
"Imagination is more important than Knowledge. Knowledge is limited,
Imagination encircles the world." ~Albert Einstein
  #2  
Old February 23rd, 2010, 06:57 PM posted to microsoft.public.access.tablesdbdesign
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Efficient Table Design Questions

On Tue, 23 Feb 2010 08:15:01 -0800, Monet 138
wrote:

I'm working on a Project Manager DBase for our engineering department. One
of the things they want to be able to record within each project is the Size,
Length and Material of the pipes installed. They also want to be able to run
reports that would provide them totals based upon region, year, etc.

So I'm looking at sizes ranging from 1/2" to 48" (approx 20 different sizes)
plus a wide range of possible materials for each size.

Question 1:
Since a project could have multiple materials of the same pipe size
installed, do I create a field for each possible size & material combination
paired with its own length field, which would mean approx 100 or more fields.
Or if I estimate that a max of 20 size-material combinations would ever be
needed in a single project, would using a field-set similar to the example
below still work well enough for the totaling reports?

Size_1 | Material_1 | Length_1 | Size_2 | Material_2 | Length_2 |Size_3 | etc.


Access (and all relational tables) should be tall and thin, not wide and flat!
You don't want another *FIELD* for each size, you want another *RECORD*.

The Pipe table should have a field for material, size and length (and perhaps
quantity used, e.g. if the project uses 125 12' pieces of 2" PVC...). If a
project involves 312 kinds of pipe... you'ld have 312 records in this table.

Anyone have a suggestion for something better than the two options I outlined?

Question 2:
Since the size-material quantities will be unique for each project, is there
any reason to actually seperate this information out into a second table or
should it just be kept within the primary table?


Almost certainly a second table.
--

John W. Vinson [MVP]
  #3  
Old February 23rd, 2010, 07:14 PM posted to microsoft.public.access.tablesdbdesign
Jerry Whittle
external usenet poster
 
Posts: 4,732
Default Efficient Table Design Questions

You are thinking across like using an Excel spreadsheet. This will cause you
grief.

Instead you nee to thing down like a database. At the least you need a table
for Projects. It would have a Project_ID primary key field (make it an
autonumber), Project_Name, StartDate, Region, etc.

Pro_ID ProName ProDate ProRegion
1 Back40 1/1/2010 4
2 Ten40 2/2/2010 3

Then you would have another table for Pipes. It would have a Pipes_ID
primary key (autonumber), Project_ID (foreign key to the Projects table),
Size, Lenght, Material, and Quantity.

Pipes_ID Pro_ID P_Size P_Lenght P_Material P_Qty
1 1 1/2" 12" PVC 3
2 1 24" 4' Copper 1
3 2 2" 47" lead 1

You might even want to create tables that list the commons sizes and another
table for the common materials so that they could be looked up easily in a
combo box or list box.

Join these tables together in the Relationships window with Referiential
Integrity enabled. Don't worry about cascade update or cascade delete.

Create a form for the Projects table and on it put a subform for the Pipes
table. That will keep things together properly. You open up the form and put
in the Projects data. Then you can fill in the pipes as needed on the subform.

You can create queries and reports based on these tables as needed.
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"Monet 138" wrote:

I'm working on a Project Manager DBase for our engineering department. One
of the things they want to be able to record within each project is the Size,
Length and Material of the pipes installed. They also want to be able to run
reports that would provide them totals based upon region, year, etc.

So I'm looking at sizes ranging from 1/2" to 48" (approx 20 different sizes)
plus a wide range of possible materials for each size.

Question 1:
Since a project could have multiple materials of the same pipe size
installed, do I create a field for each possible size & material combination
paired with its own length field, which would mean approx 100 or more fields.
Or if I estimate that a max of 20 size-material combinations would ever be
needed in a single project, would using a field-set similar to the example
below still work well enough for the totaling reports?

Size_1 | Material_1 | Length_1 | Size_2 | Material_2 | Length_2 |Size_3 | etc.

Anyone have a suggestion for something better than the two options I outlined?

Question 2:
Since the size-material quantities will be unique for each project, is there
any reason to actually seperate this information out into a second table or
should it just be kept within the primary table?

Thanks for the help.

--
"Imagination is more important than Knowledge. Knowledge is limited,
Imagination encircles the world." ~Albert Einstein

  #4  
Old February 23rd, 2010, 07:27 PM posted to microsoft.public.access.tablesdbdesign
Monet 138
external usenet poster
 
Posts: 7
Default Efficient Table Design Questions

Thank you very much. That was exactly what I needed.

--
"Imagination is more important than Knowledge. Knowledge is limited,
Imagination encircles the world." ~Albert Einstein


"Jerry Whittle" wrote:

You are thinking across like using an Excel spreadsheet. This will cause you
grief.

Instead you nee to thing down like a database. At the least you need a table
for Projects. It would have a Project_ID primary key field (make it an
autonumber), Project_Name, StartDate, Region, etc.

Pro_ID ProName ProDate ProRegion
1 Back40 1/1/2010 4
2 Ten40 2/2/2010 3

Then you would have another table for Pipes. It would have a Pipes_ID
primary key (autonumber), Project_ID (foreign key to the Projects table),
Size, Lenght, Material, and Quantity.

Pipes_ID Pro_ID P_Size P_Lenght P_Material P_Qty
1 1 1/2" 12" PVC 3
2 1 24" 4' Copper 1
3 2 2" 47" lead 1

You might even want to create tables that list the commons sizes and another
table for the common materials so that they could be looked up easily in a
combo box or list box.

Join these tables together in the Relationships window with Referiential
Integrity enabled. Don't worry about cascade update or cascade delete.

Create a form for the Projects table and on it put a subform for the Pipes
table. That will keep things together properly. You open up the form and put
in the Projects data. Then you can fill in the pipes as needed on the subform.

You can create queries and reports based on these tables as needed.
--
Jerry Whittle, Microsoft Access MVP
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"Monet 138" wrote:

I'm working on a Project Manager DBase for our engineering department. One
of the things they want to be able to record within each project is the Size,
Length and Material of the pipes installed. They also want to be able to run
reports that would provide them totals based upon region, year, etc.

So I'm looking at sizes ranging from 1/2" to 48" (approx 20 different sizes)
plus a wide range of possible materials for each size.

Question 1:
Since a project could have multiple materials of the same pipe size
installed, do I create a field for each possible size & material combination
paired with its own length field, which would mean approx 100 or more fields.
Or if I estimate that a max of 20 size-material combinations would ever be
needed in a single project, would using a field-set similar to the example
below still work well enough for the totaling reports?

Size_1 | Material_1 | Length_1 | Size_2 | Material_2 | Length_2 |Size_3 | etc.

Anyone have a suggestion for something better than the two options I outlined?

Question 2:
Since the size-material quantities will be unique for each project, is there
any reason to actually seperate this information out into a second table or
should it just be kept within the primary table?

Thanks for the help.

--
"Imagination is more important than Knowledge. Knowledge is limited,
Imagination encircles the world." ~Albert Einstein

 




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:16 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.