I really never want to assume order in tables. That's because there could be many orders of interest, and that's one reason to have multiple indexes. And also because for a table, the order of rows can be hard to guarantee. Obviously something like qSQL would try hard to guarantee table row order, and that's great in the cases where qSQL is useful, but more generally it's going to impose on how you work with the database.
On the other hand, SQL is set-based. But being set-based is weird in the world of computers because in memory everything is ordered. Sets are a fiction in programming, as they're always ordered in some way, and the set abstraction can only try to hide that order.
And that order can be very useful.
But there can be many orders that can be useful, but only one in which things are stored in memory -- the others can only be extra indexes.
So the general purpose thing (SQL) has to be set-based, offering explicit ordering, and taking advantage of actual order for optimization.
On the other hand, SQL is set-based. But being set-based is weird in the world of computers because in memory everything is ordered. Sets are a fiction in programming, as they're always ordered in some way, and the set abstraction can only try to hide that order.
And that order can be very useful.
But there can be many orders that can be useful, but only one in which things are stored in memory -- the others can only be extra indexes.
So the general purpose thing (SQL) has to be set-based, offering explicit ordering, and taking advantage of actual order for optimization.