Am I on the Right Track
- Thread starter Huxxxy
- Start date
HiTechCoach
Well-known member
- Local time
- Today, 13:17
- Joined
- Mar 6, 2006
- Messages
- 4,353
It helps to know what processes you database must handle. Without knowing what you need to do it is really hard to is say much.
There are some thing that apply tio every data that you need to address::
1) Do not use reserved words for field names. Example: Date or Description should not be use as a field name.
2) every table needs an auto number field. It is best to make this the primary key.
I would avoid using compound/composite (multi field) primary keys . I have found that they will cause you many headaches and can usually be avoided. I would use compound/composite (multi field) indexes set to no dups.
There are some thing that apply tio every data that you need to address::
1) Do not use reserved words for field names. Example: Date or Description should not be use as a field name.
2) every table needs an auto number field. It is best to make this the primary key.
I would avoid using compound/composite (multi field) primary keys . I have found that they will cause you many headaches and can usually be avoided. I would use compound/composite (multi field) indexes set to no dups.
This is pretty hard to explain in just a few words. I studied database design for an entire semester at school. It was complete with a 300 page textbook on the subject! But I will give it a try.
One way to approach this is to model your tables after the situation. First try to find each of the entities. From what your telling me, this database would have a Job table, a part table, and a location table.
No you need to ask yourself, "How do these relate?". Are there many jobs to many locations? Are there many parts to many jobs? If so, then you have two many-to-many relationships.
Another, more simple relationship, is the one-to-many. For instance, a person may have many phone numbers; home, cell, work, fax, etc. In turn, each phone number would only have a single person. This would be a one-to-many relationship.
For more information, I suggest doing a web search (or Google it, as they say now) on one-to-many and many-to-many relationships. Also I suggest searching on "normalization" and "database design".
What I am trying to aim for is:
Each batch of parts have a Unique workorder number - they come with a jobcard which has a range of operations to complete the batch of jobs.
There are many operations that need to be completed at a range of workcentres but each operation needs to be logged, eg - Good parts, Scrap parts and process time and when a batch is moved on to a different operation I want the qty with the scrap deducted etc.
Also if the batch is awaiting to be run I want a query to tell the operators which tray the batch is on and what workcentre its awaiting.
Work Order - 123456
Part Number - 123-123-123
Operation - 010
QTY - 256
WorkCentre - Evo50
So From each batch thats run in the week I want to pull data - Defective parts per million and OEE.
Each batch of parts have a Unique workorder number - they come with a jobcard which has a range of operations to complete the batch of jobs.
There are many operations that need to be completed at a range of workcentres but each operation needs to be logged, eg - Good parts, Scrap parts and process time and when a batch is moved on to a different operation I want the qty with the scrap deducted etc.
Also if the batch is awaiting to be run I want a query to tell the operators which tray the batch is on and what workcentre its awaiting.
Work Order - 123456
Part Number - 123-123-123
Operation - 010
QTY - 256
WorkCentre - Evo50
So From each batch thats run in the week I want to pull data - Defective parts per million and OEE.
