>
>After thinking about my own problem, I thought I'd think more about yours. I'm imagining your worst-case scenario as a database that contained everything there was to know about everything sold in a department store. Such a client would have to accept a very large number of tables, which would not store Waist and Length in the Lawnmowers table and would not store Engine Displacement in the Pants table. But I suppose that the stuff your client sells is all similar
>You could make a compromise between these two models, if for example there were a few groups that were fairly constant and consistent and very different from each other. They would each get their own table and maybe their own table of metadata.

I think the real trick here is to carefully analyze the grouping/subgrouping of products and come up common features, etc. Just like you'd do with any normal class design. Once you have that, I think it should be relatively easy to come up with the necessary database structures to support it.

If you're using my table layout, any options common to all products might get added as columns to the Category table. Any custom options for an individual category probably belong as a new table with a foreign key to it in the Category group table. It could be possible that you end up with a lot of different tables describing the objects. If that's a problem, you could use a single table with a memo field and fill it with custom options. The product table would just need a foreign key pointing to the category group.

If you use a memo for the options, you could make the options be parameters to a class, and a class to instanciate to handle them (ala Abstract Factory "plus"). There are a lot of different ways to handle this - it'll probably take some planning (and playing) to find the best approach. It should be an interesting project.