[G.....n]

Mamy tabelę, robimy z niej SELECT z kilkoma joinami bez order by.
W jakiej kolejności zostaną zwrócone wiersze:
1) w kolejności wg klucza głównego
2) wg kolejności wg ułożenia w indeksie użytym w planie zapytania
3) dowolnej
Zgadza się, wszystkie odpowiedzi mogą być poprawne:
- specyfikacja mówi o dowolnej kolejności
- z planu wykonywania zapytania zwykle jest używany klucz główny (bardzo duże uproszczenie)
- zwykle najbardziej poprawną odpowiedzią jest 3
- chyba że w zapytaniu zostało wykorzystane kilka procesorów

Wniosek? Jeśli chcesz mieć posortowane dane to poproś o posortowane dane.
#sql

[File_not_found]

@Ginden: Jest tu jakaś różnica pomiędzy Oraclem, MSSQL czy DB2?

[G.....n]

@File_not_found: Możliwe, że w części dotyczącej wątków. Reszta powinna się zgadzać.
Anyway - jeśli chcesz posortowane wiersze, to robisz order by. Nigdy nie należy polegać na tym, że testowe zapytanie zwraca nam je w takiej kolejności jak chcemy - bo przy innej ilości RAMu, innej liczbie procesorów, innej liczbie wierszy w tabelach czy rozkładzie danych może zwrócić je w całkiem innej.

[plushy]

@Ginden: To nie do końca jest tak z tą dowolną kolejnością. Kolejność nie jest gwarantowana ale nie oznacza to absolutnie dowolnej kolejności, są kombinacje które nie mogą wystąpić.

No i najważniejsze: Jesli nie potrzebujesz posortowanych danych to nie proś o ich sortowanie.

[G.....n]

@plushy: Gdzie specyfikacja zabrania jakiejś kolejności?

[plushy]

@Ginden: Spec6fikacja nic nie zabrania. Ale nie zdarzy się tak że zwróci ci je w losowej kolejności. Jeśli zostanie zmieniona kolejność ze stronic to będzie to związane z określonymi operatorami fizycznymi, nie uzyskasz wszystkich tych kombinacji jakie byś dostał sortując po rand()

[G.....n]

Spec6fikacja nic nie zabrania. Ale nie zdarzy się tak że zwróci ci je w losowej kolejności. Jeśli zostanie zmieniona kolejność ze stronic to będzie to związane z określonymi operatorami fizycznymi, nie uzyskasz wszystkich tych kombinacji jakie byś dostał sortując po rand()

@plushy: Specyfikacja nie zabrania - to, że się nie zdarzy coś takiego, wynika ze szczegółów implementacji. Równie dobrze można by dodać kod w dowolnej open source'owej bazie danych, który miesza

[plushy]

@Ginden: Oczywiście że specyfikacja mówi jedynie że kolejność nie musi być zachowana gdy brak ORDER BY, ale wiedza co się dzieje naprawdę się przydaje w debugowaniu szalonych aplikacji. Miałem problemy z taką jedną gdzie funkcja przyznawała kilku procentom ludzi zły status bo brała nie ten rekord co trzeba, a rekordy były wsadzane do tabeli naraz jeden po drugim i zwykle ten pierwszy się łapał.

[nieSluchamSieMamy]

@Ginden: Teoria: baza zwróci dane w dowolnej kolejności. Praktyka: dane zostaną zwrócone w takiej kolejności, w jakiej są zapisane w bazie danych. Dane są zapisane w bazie "mniej więcej" w tej kolejności w jakiej wrzucaliśmy inserty. Sprawa się kompiluje w przypadku tabeli gdzie jest dużo wierszy usuwanych i wprowadzanych.
W przypadku łączenia tabel to możemy jedynie szacować kolejność na podstawie planu zapytania. Plan zapytania bazuje na statystykach i może się zmieniać

[G.....n]

Praktyka: dane zostaną zwrócone w takiej kolejności, w jakiej są zapisane w bazie danych. Dane są zapisane w bazie "mniej więcej" w tej kolejności w jakiej wrzucaliśmy inserty. Sprawa się kompiluje w przypadku tabeli gdzie jest dużo wierszy usuwanych i wprowadzanych.

@nieSluchamSieMamy: W takiej w jakiej są zapisane w źródle z którego pobieramy.
Jeśli pobieramy z indeksu to pobiera wg kolejności w indeksie zwykle. Kwestia tego co wybierze optymalizator zapytań.