I had considered that, but it didn't really seem pertinent to my original post. The two reasons I discounted that solution were: 1) I didn't necessarily need the subid to be unique unto itself, which leads to 2) I wanted the keys to be small, and easy to enter for an operator, or easy to encode into a barcode.

The specific item that launched me along this idea was Fuel. The person I'm writing this for sells a lot of fuel to pit crews on local race tracks. He sells it by pump, and also in pre-prepared 5, 6.8, 15 and 20 gallon drums. I wanted a way to reference these pre prepared amounts without having to create seperate items.

So, the way I've envisioned it.. you have Fuel in the baseitems table. It has an 'id' of 1000, which is easy to remember. Then, in the items table, you'd have a row with an 'id' of 1000 to reference it's a fuel item, and then a subid of 5: this would reference the 5 gallon drum. The subid is arbitrary, and really isn't meant as a unique identifier as it is a suppliment that should be easy to remember and relates to the packaging.

So, when someone gets to a prompt for what item the customer is bying, they can just type '1000-5' or '1000-15' or '1000-68'.. which would be just a composition of the baseitem key, and the subid. It all lines up rather nicely, and it makes barcoding the products easier too.

Regardless, I provide all of this as an aside. I'll just have to code up the linking methods and the triggers and all that happy stuff by hand, or come up with a programmatic way to do it and jam it into the Class::DBI space. I appreciate your input and suggestions.