If I make a table for everything, wouldn't it necessarily have way too many fields with most of them being blank for most items?
No, because individual tables should not be exact duplicates of each other. The entity (what the table is for) has attributes (fields for characteristics) only for that entity, so you wouldn't include fields from other tables that don't apply.
My advice would be a table for each tool type where the characteristic data you need is common. So if all you will ever want for lifting devices is manufacturer, model, serial and capacity, then one table for these would suffice. However, if you want to distinguish between chainfalls and pullers, then the decision is to have another table or an LDType (Lifting Device Type) field in tblLiftDevs. Just using an example of how the thought process might go. However, lamps, refrigerant, measuring devices have no relationship to drills so why have a fields in a table for refrigerant gas type and chuck size? Not good design. Seeing as how we don't edit records directly in tables (right?) but only in forms, it matters not how many tables you have as long as you don't exceed the limit (which I think is 255).
Speaking of forms, your design might benefit from the use of a tab control (or more than one) where each page is for a tool category, or maybe type. I have see this sort of thing done before where each table is a category listing and the ability to drill down was done through cascading combos. Hopefully I can provide you with at least a bit of guidance as I'm quite familiar with industrial tools and tool crib equipment.
Last edited by Micron; 05-18-2018 at 09:46 PM.
Reason: correction
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.