Question

Essentially, I would like to create a database structure that allows for classifying an infinite amount of inventory items in an infinite amount of ways, however, many of these items share certain “traits”. Take, for instance, Cars and Trucks:

• Both can be red or blue only.
  • Either color car/truck can be 2wd or 4wd.
    • Cars can have manual or automatic transmission.
    • Trucks can have cloth or leather seats
    • etc….

The thing I am looking to avoid would be manual entry of every possible combination that exists. With 5 colors and 5 vehicles, that’s already 25 entries and no feature set classifications.

Is there a data model that allows for these relationships and shared “groups of traits”, or more importantly, one that allows for a single reference to each possible combination of any set of data I can imagine? Any help would be greatly appreciated.

Updated [2012-01-23]

Let me be as specific as possible. My main goal is to track material usage
on jobs we are doing for budgetary and historical purposes. Some materials,
i.e. studs and track, will share the same sub-classifications, with
track having yet a 3rd sub-classification. Some will have completely
different sub-classifications. Assume the following.

• 5 possible metal_widths
• 5 possible metal_gagues
• 4 possible track_types
• 5 possible insulation_widths
• 3 possible insulation_types

…the relationships (possible combinations):

• Studs > metal_widths > metal_gagues (25)
• Track > metal_widths > metal_gagues > track_types (100)
• Insulation > insulation_widths > insulation_types (15)

Just to get an idea of my ultimate goal, the application workflow would be
something like this:

1. Create a job.
2. Create a job budget.
   • Set a budget amount/cost for each material I expect to use.
3. Begin entering material invoices.
   • Set an amount/cost for each material on the invoice.
4. Track/Review my budget estimates vs. actual cost.

I think the goal of my budget vs cost application is pretty straight forward,
I just want to get the design of the material-related database correct before
moving forward. I realize the easiest solution would be to create a single
entry for each possible combination in a material table and limit that
database to n number of possible traits. The problem is that when I decide to
add an x width stud, I also want to add an x width track, meaning I’ve
increased the possible combinations by 30, and therefore require 30
additional entries (which I’d really rather avoid).

My question remains the same: Is there a data model that allows for these
relationships and, more importantly, is there one that allows single reference
points for each possibility… or, should I scratch this notion and go with
single entries for each material and limit the number of traits.

Answer 1

You mean something like this?

This simple model allows you to group the traits together and then “apply” the whole trait group to an arbitrary number of items (the ITEM_TRAIT_GROUP table is a typical example of how an M:N relationship can be represented in relational paradigm). If your primary concern is to avoid repetition through “reuse” of traits this model might fit the bill.

This, however, will not enforce:

1. any particular trait group onto a specific item kind (such as cars requiring a color) nor any particular relationship between traits (such as seat material having to go together with the seat color),
2. nor will it limit values for any particular trait (such as color having to be “red” or “blue” but not, for example, “green”).

(1) and (2) would demand some sort of type system and even “inheritance” (in OOP sense), which is no fun in relational paradigm. If you really need it, you are probably better-off enforcing this kind of logic at the client or middle tier.

The (3) can be reasonably modeled relationally, but not without complicating the model, which may or may not be worth the effort.