Re: database design
Date: Sat, 21 Jul 2001 23:27:15 GMT
Message-ID: <rMeR6.1707$J23.379378_at_paloalto-snr1.gtei.net>
Forget the "query over a large number of tables" and concentrate on revising the database design. Your currently-planned design would be unmanageable. You may even need to find a qualified consultant to advise you on this to make sure you get the design right.
If you are saying that _each_ of the 10,000 records will have certain unique-to-the-individual-record fields, then I think you may have to create either a text field, or several text fields, or a related table. If you choose a related table, you can have one field that indicates what the data _is_ and a second containing the _value_.
On the other hand, as is probably more likely, you will have several different categories of part, each category having several category-specific fields.
Clarify a bit more and perhaps someone can provide other suggestions that may be more useful.
"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:15 CEST