Comment by RaftPeople

I wrote a cubing/containerization system in SQL, but it did use the additional capabilities in a sproc for looping etc., so not just a single SQL stmt.

But the problem actually mapped well to SQL's capabilities in some ways. The basic algorithm was:

1-Loop through items in descending size order

2-Test X different positions and orientations such that one corner is butted up against an existing corner (of container, or previously placed items, etc.)

3-Choose the winner based on some sort of point systems that encapsulates some set of rules (e.g. preferred orientation, or minimizes small gaps between sides of items, etc.)

These were some aspects that lined up well with SQL:

A-Testing of X number of positions and orientations all with a relative simple statement, using as input: existing corner points from previously placed items, some control table with the variations in X,Y,Z orientations.

B-The ability to maintain a set of previous options for each iteration (e.g. item #2 was tested in these positions with these stats and all are temporarily being considered reasonable options), add new item to each one of those previous tests and accumulate stats. It was pretty easy to configure a "window" of how many different open options were being tracked to optimize the result without overwhelming memory. The SQL to include the options was almost the same as if there was only one previous chosen option.

Some aspects were a bit painful to shift the model mentally to fit in with SQL.