>The "high degree of matching" is what I am aiming for. The best analogy of what is happening, that most people here can probably relate to, is the production facilities of say Dell Computers. Multiple orders are received more or less continuously, where each order has small variations - size and type of disk drive, amount of RAM, type of mother board and CPU, etc.
>
>In my case the scale is considerably smaller - the number of jobs in the queue is typically between 150 and 200, only two production lines, during a typical day there might be 24'ish product configurations.

That doesn't sound too bad (I had initially pictured "thousands" of parts).

Using the DELL example and 24'ish major "components", I would proceed as follows (as a starting point):

Create a "denormalized" table that reflects the Job queue and parts requirements; eg.

Job # | Board | CPU | RAM | DRIVE | Graphics Adapter | ..
123     ASUS    4GHZ  256   40M     Matrox
986     ASUS    ...

Populate this table from your "Jobs and Parts" tables (It might be as simple as UNIONing all the Job-Part records on Job Number ... after selecting each part type out to a different column)

Once this table is populated, it may simply be a matter of sorting the columns in a particular order to come up with a "workable" schedule.

The (initial) suggested sort order would be to sort first on the part that "varies" the least (ie. fewest options), then on the part with next fewest options, etc.

This should at least group together all identical jobs :)