# Data structure and algorithm for multidimensional “volume rental” scheduler

Abstract problem. Imagine the world is a cube, made of multiple cubical cells along all the dimensions of the cube.

Now, imagine you are able to rent certain volumes for certain periods of time, for example: you rent a 3x3x3 volume with coordinates [1, 1, 1] to [3, 3, 3] for year 2012. Then you rent a 2x2x2 volume with coordinates [4, 1, 1] to [5, 2, 2] for year 2012.

Now, imagine you are able to let out volumes that you have rented, in periods for which you have acquired them. For example, having rented the volumes as defined above, you let out a 5x2x1 cell volume with coordinates [1, 1, 1] to [5, 2, 1] for Q1'2012. Then youlet out cell [5, 2, 2] for the whole year 2012.

You can rent the same volumes in multiple "rental contracts", and let them out, also in multiple "contracts".

The question is - what data structures and algorithms can be used to answer questions like:

• When can I let out a certain cell?
• What cells can I let out in a certain period?
• Can I let out cells of certain coordinates, not including all the dimensions (e.g.: someone wants to rent any cells that have coordinate X between 2 and 4 for year 2012)?

A brute force approach (try every combination to check) is out of question. The data set I need this to work is 5-dimensional (with more dimensions potentially coming soon), and the dimensions are 100-200 items long on average.

If you treat time as just another dimension then what you describe looks like the sort of queries you might expect to want to pose about any collection of objects in n-dimensional space.

That suggests to me something like http://en.wikipedia.org/wiki/K-d_tree or possibly some n-dimensional version of http://en.wikipedia.org/wiki/Octree. The catch, of course, is that these datastructures run out of steam as the number of dimensions increase.

You rule out the brute force approach of checking every cell. Are you also forced to rule out the brute force approach of checking each query against each known object in the n-dimensional space? Since everything seems to be an axis-aligned n-dimensional rectangle, checking for the intersection of a query with an object may not be hard - and this may be what you will get anyway if you attempt to duck the problem by throwing it a database query package or some very high level language - a database full table scan.

As mcdowella points out, Octree and k-d trees lose efficiency as the number of dimensions increased beyond about 4 or 5. Since you haven't said what the dimensions are, I'm going to assume they are properties of the objects you are talking about. Just put them in an RDBMS and use indexes on these fields. A good implementation can have good performance doing a query against multiply-indexed items.

If your dimensions have binary values (or small enums) then something else will likely be better.