SQL deals with tables, and all operations are working on tables. However... these tables are bags of rows, not sets, as evidenced by:
1. "distinct" transforms bags into sets
2. "union all" preserves bags
3. the ability to create a table with no primary key, allowing entirely duplicate rows in a table
4. the ability to select columns not including a primary key, allowing duplicate rows in the resulting table
> ... which are unordered
While (base) tables themselves guarantee no order:
1. every "select" is itself returning a table, which can absolutely have an order.
2. a "view" is a (derived) table, and it can guarantee an order
3. aggregate functions rely on ordering
> I think this is an excellent design.
Your approach would be an excellent design.
SQL deals with "sets", which are unordered,
and the user needs to specify the order by if
they need sorted output. I think this is an
excellent design.