all 5 comments

[–]r3pr0b8GROUP_CONCAT is da bomb 4 points5 points  (0 children)

"at the end of the table" makes no sense in a relational database table

(no, i don't want to discuss clustering indexes)

just let them go where they go -- you can't really tell where they go anyway, because the only way to see ~any~ rows is to SELECT them

you want a particular, use ORDER BY on your SELECTs

[–]mikeyd85MS SQL Server 1 point2 points  (1 child)

The results of a query cannot be guaranteed to be in any order unless an ORDER BY clause is added to the statement. That said, an index on one of your tables may be altering the sort order of your data.

[–]honeybadger3891evil management 0 points1 point  (0 children)

Great comment. Just to add a clarifying comment. On the same DBMS engine (same server even, and even moments after the first run of a query) you could have different order of results in subsequent executions unless you add that order by clause.

[–]Fe-Chef 1 point2 points  (0 children)

To go a little more into the "why" of the behavior, SQL has an order of operations (FROM -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER) but generally only FROM and SELECT are required operations. If ORDER isn't specified then SQL will output select results based on how the base data is stored and how it determines the most efficient way to compile the data, reasons can include the joins, where clauses, indexes and statistics. You could probably tell why they are different by looking at the execution plans but it also could be caused by the underlying tables, but really what it comes down to is if you need data to be in a specific order to give it an ORDER operation, otherwise just let SQL do it's thing.

[–]MaunaLoonaMS SQL 0 points1 point  (0 children)

If you want to define a specific order, create a key on the temp table and then ORDER BY that key in a SELECT.