[web] flightpath calculation and optimization

a bit more detail:
the coordinate system is a standard 3D x,y,z system

each cube is represented as following [x;y;z] ex:[-35;-0;-30]
these coordinates are the center of the cube. cube size and distance between cube center is controlled by 2 variables.

i think i will have to add a new table with a cells for each x, y and z coordinate that way i can create the query a lot easier (with between) but the amount of rows could quickly go into 100's of thousands even millions.
in this system every cube linked to a fleet would gets its row

...To avoid to have to perform a series calculations on all fleet in movement i devised a method where a flightpath is broken up into overlapping cubes. when a new flightpath is added it just checks the cubes in other flightpaths...

Your "...just checks..." sounds to complex. If i understand you right, than i would store a fleets path in another way than you described it. Let me explain:

-----------------------------

Your space system is divided into cubes (like an octree). A fleet follows a path from A to B and passes different cubes while moving. But at any specific time, it just passes ONE cube. Save this cube in your database, along with the time when it enters this cube and when it leaves this cube, which both depends on the flight path. You can precompute the time, when a fleet leaves its current cube (or "sector" so to speak). Simple math! In addition, save the 3D point, where the fleet enters that cube and where it will leave it (for path reconstruction later on).

Now do that for all cubes of the fleets flight path and save all in the database (a table with 6 columns: path_id, cube_id, time_entering, time_leaving, point_entering, point_leaving). So, if a fleet moves now, there a several rows saved in the database, consisting of a number of cubes (each one has its own table row). And all belongs to your fleets current path (= path_id)

-----------------------------

Now, if you compute the path of another fleet, you will get their according cubes too. You can check then the current cube where the fleet belongs to against all rows in the database of the same cube, where current time is between entering and leaving time of the other path ids. (the according select query is really simple)
If you found another fleets path this way, you know there a two fleets in this sector at the same time. You know both paths (thanks two the two time values and points saved for each cube). Now you can check, if they intersect while moving through this cube/sector.

...cube size and distance between cube center is controlled by 2 variables...but the amount of rows could quickly go into 100's of thousands even millions...

No, your cubes/sectors would be defined because they build up the coordinate system. Just don't make the cubes to small. Maybe a normal flight path passes through 10 cubes. 10000 rows for 1000 moving fleets aren't much for a database. Whenever you have to compute a path, you just have to check ONE cube/sector and all the other fleets of the current time frame in there.

I hope you did understand what i wanted to say

thanks I understand what you mean. I'm going to use a adapted version of what you said.

thanks a lot