Data cubing is a fantastic topic. The systems which do real-time cubing are incredibly finicky. It's actually not a simple problem to solve to be honest.
Having written a couple of systems which do it in the past and now working with one at Space Command HQ, I'm quite pleased that the Big Brains at SCHQ have, basically, produced exactly what I did. An in-memory database of terrifying complexity, astonishingly bad error reporting and a tendency towards alienese gobble-de-gook when it comes to config and query languages.
So I've come to a conclusion.
Implement SQL in them.
Now.
Really, I know it looks like a pain, and it doesn't really need it. And that you really just need a nice simple scripting system and you can just bolt a little bit to it here and little bit to it there.
And before you know it, what was a simple little scripting language has turned into something that's the size of a medium battlecruiser, hovers in the air, glows with a alien purple light and explodes at the slightest provocation.
SQL is a faffy bastard, exactly because people spent a long time hammering it into a shape where it fits exactly into its distorted little universe. So, when you need a query language, just bite the bullet and implement some subset of SQL. You'll end up implementing something of that order of complexity anyway, you might as well set out down the right path rather than having to hammer all your own glowing purple components from scratch.
It's like most other things. Really just embed a lua interpreter or a python interpreter.
Because your "nice simple" config language will tend to just get bigger and bigger and bigger. Like those alien tendril things we're always clearing out of the bilges. Only instead of the slightly comical but ultimately horrifying staring orange eyeballs, config languages sprout things like macro expansions. If you're in a super smart environment, you also get cute little Lambda expressions with which to make the complexity explode.
You also get really weird variable expansion rules. One of the languages at SCHQ simply can't express the percent symbol because none of the several uses for percent have escapes back to a literal percent...
You might as well just start out with a turing complete language, into which you can plug query systems and so on. Rather than having a makefile which invokes python to create some config files full of lambdas which expand to macros which expand to settings for things... just use python to start with.
Part of the reason for this is the YAGNI approach. Everyone starts with flat text files and smoothly transitions to all the pain of maintaining a TC language without ever passing a point where someone says "No, stop! Just use an existing language!"
Obviously the point to do that then, is before you do ANYTHING more complicated than a genuinely flat text file. The minute you start considering something like shell variable expansions, it's time to stop and do it properly then.
