Re: database design

Jim
I am in the process of setting up a similar thing for the company I work in. I structured it round what I assume a typical MRP BOM looks like behind the scenes. Each product is in the same flat file that has an index number. It is attached to the next level up by using the index field in a receiver field; all within a flat file. To get the seperate headings for each product or module, I used a seperate table for all the headings for that part, and called them up in a sub-form when you select the Part number you want to enter data for. We have about 500 parts, each with potentially about 75 'facts' relating to it. There are just two main tables, headings and data, its very compact.

If you want and can wait a week or two, i will send you a copy. I plan to do some sort of SPC on some of the parameters too. Oh, and it can reject things, record root causes, and do charts of rejects by product line, as a percentage of build, and within the part it will give root causes.

If it works it will be great!!!

Paul

"jim fraser" <jfraser_at_mediaone.net> wrote in message news:40f6cbfc.0105301140.42e1defc_at_posting.google.com...
> We are trying to figure out the best way to (re)design a database for
> our Q.C. department inspection record system. There is a seperate
> paper inspection record form for each part number that is inspected
> (over 10,000). This form contains the data for all the inspections
> done on this part over time. The form (inspection record) contain
> mostly all common fields except for a handfull of fields that are
> unique for each part (its paticular inspection requirements).
> Currently we are developing a flat file database with a seperate table
> (over 10,000) for each part (looks just like the paper form). The
> problem is trying to perform a query across all tables. Does anyone
> have any ideas on how to perform a query with this large table count
> or a better database design idea?
Received on Sun Jul 22 2001 - 01:27:06 CEST