I have a table -

TableID
PartNum
PartName
InstallTime_Shop
InstallTime_Site
InstallTime_Cadd
InstallTime_Testing


InstallTime Is a set amount of estimated time per part. This Value would be used to estimate time needed to install a part.

Should InstallTime_ be in its own table?

If it is in it own table would it one to one?

I have a table -

TableID
PartNum
PartName
InstallTime_Shop
InstallTime_Site
InstallTime_Cadd
InstallTime_Testing



What's the table for? It's not very descriptive. In other words, what one object is this table supposed to represent in the grand scheme of things?

I may be tempted to move all the 'Install' data to a seperate table.

Edit: Because you could have many parts with no 'Install' data or maybe even the install data is irrelevant to certain parts...

See the names:
InstallTime_Shop
InstallTime_Site
InstallTime_Cadd
InstallTime_Testing

This begs for a table with a PK, FK back to (part table?) and a code to seperate the SHOP, SITE, CADD and TESTING. Since all these start with "install Time" it is basically duplicated data. I would also have a lookup table storing a PK and the values SHOP, SITE, CADD and TESTING, with a FK in the INSTALLTIME table to point to which it is.

Part Table!
TableID (Note these should be more descriptive, but I will use it)
Part Number
Description

InstallTime Table!
ITableID (PK)
PartTableID (FK to point to Part)
TypeInstallID (FK for type of install)
ITime (time it takes)

TypeInstall Table!
TITableID (PK)
ITableID (FK)
Description (SHOP, CADD etc.)

Now you can create a combo box using a query against TypeInstall table to select the installation type.
Install times can be a subform on your main part form.

As an example.

This is getting close to overkill (IMHO). Hum... But it would allow you to analyze install times easier across sites, shops, etc, if you needed to...

What's the table for? It's not very descriptive. In other words, what one object is this table supposed to represent in the grand scheme of things?

Sorry I just put a real basic description up. This is part of what I hope will be a database tool used by several groups of people.

The part I am working on now is a material list. I am tiring to plan it out on paper and white board before I attempt to build it.

So...

Table 1: tbl_Material_list
mat_list_ID
mat_list_partnum (manufactures part number)
mat_list_partnames (short name)
mat_list_partnamel (Long Name)

I will then have A
Manufactures list table (who makes it)
Vender list table (Who sells it to us)


Then I got to install time.
Every part in the material list will have an install time even if that install time is 0.

There will be a form to build a quote for our customers. In that form a sales person can select multiple parts at multiple quantities and have the form show the amount of time in each area that will be needed. Then I would go from there to add labor rates ect.

I think I understand normalization in that similar items should be grouped together, thus install times would have there own table. But in this case I am confused. These items won't be used anywhere else. And each item would have a total install time of Shop + Site + Cadd + Testing. (Not stored in the database) It would seem harder to calculate if any one of the values was a null value. It just seems unnecessary to have a one to one table.

Question:
Next year they decide to add off-site install time. Now what?
Just add an entry to the lookup table and everything still works fine, or change the whole application where all those fields are referenced?

I think I understand.

Thank you all for the replys.

Question:
Next year they decide to add off-site install time. Now what?
Just add an entry to the lookup table and everything still works fine, or change the whole application where all those fields are referenced?

Good point :)

I probable should have started a new thread but this is still along the same lines.


Now I am looking at a list of Venders.

I copied a table from a sample access database. (Inventory control - table suppliers) thinking I would be safe. But as I looked at it I saw the contact info

ContactName
ContactTitle

The first thing I thought was I needed to split The Name

ContactFirstName
ContactLastName

Each contact would have other details like phone number, fax, and email

All of the items are in one table in the sample database but I read somewhere on this site that Microsoft did not normalize the samples.

So I thought No problem, I would just build another Table for the Contact info.

(Some times I over think things and this might be one of those times.)

I also thought other tables in this database will need Contact info

Our Customers
Our Employees

Just to name a few.

So the real question is do I build one table of Contacts or one for each type of contact or even just leave in the main table.(although I doubt the last case.)

Depends.
You can build a single table to hold "people" and all the associated information unique to each person.
Now, is this information different for Contacts, Vendors and Employees (or what have you)? Is it different enough to warrent seperate tables?
Lets say it is not.
Now you could either have say check boxes on each record to identify them as Vendor, Contact, Employee etc. Or you could have a status identifing them as what ever, but the limitation there is then they can only be one.
You could also build a table with a code to identify the type they are and a FK pointing to each person. So say Person 123 could have a code C (customer) and a code V (vendor) in case Person 123 both bought and sold to you as an example. Doing this would allow simplify the queries, but does not have that much advantage over the check box method as long as you don't add a new type (say legal team as an example).