正確的結果，但在SQL

不同的順序我有這個疑問正確的結果，但在SQL

select s.emp_no, min(s.from_date) 
from 
**start** (select s.emp_no 
from salaries s, employees e 
where s.to_date=(select max(to_date) from salaries) and s.emp_no=e.emp_no 
group by s.salary DESC 
LIMIt 10) **end** as emps, salaries s 
where emps.emp_no=s.emp_no 
group by s.emp_no;

的開始 - 末部分是正確的。正如你所看到的，它只有一個字段包含員工的號碼。 emp_no是表格工資的外鍵。表薪水有2個領域。 emp_no和from_date。每個emp_no可以有多個from_date值。我想從工資中分組每個emp_no的所有行，並保留date_value的最小值。這顯示更正結果（我想），但更改在開始端部分創建的行的順序。關於保持訂單的任何想法？

來源

2014-06-07 Billy Grande

您可能需要添加樣本和期望的結果，但如果您想要特定的訂單，則還需要在外部查詢中進行排序。任何對有序子查詢的結果執行的無序外部查詢都可能會將結果重新排列爲僞隨機順序。 –

那麼，我如何保持外部的秩序，因爲它是在內部？ –

要回答這個問題，您需要添加一些示例數據和期望的結果，但不清楚如何按某種東西對結果進行分組，以便與原始結果完全一致。 –

您沒有ORDER BY條款。沒有ORDER BY子句，您不能指望您的結果集具有特定的順序。如果你想讓你的數據按照特定的順序出來，那麼你需要這樣訂購。這可能意味着計算內部表格表達式中的列以允許您正確地對外部結果集進行排序。你怎麼樣真正實現順序取決於你的數據，你需要什麼樣的順序是在

欲瞭解更多信息，請參閱：

困難的概念這個。 SQL規範指出結果集行的排序是不可預知的除非完全由ORDER BY子句確定。這是不可預知性是一個棘手的概念。如果您在查詢中遺漏了適當的ORDER BY規格，則您的行有時會按照您的預期順序顯示，但並非總是。通常，當您將應用程序從開發應用程序移至生產服務器時，順序會發生變化。更糟的是，當生產服務器中的某個表超過大小閾值時，它可能會在生產數月後更改。請小心。

來源

2014-06-07 12:11:39

沒錯。有時候，***但不總是***，「GROUP BY」的一個無意的副作用是將結果集按特定順序排列。 –

這可能是事實，但如果您可以明確聲明您需要以特定方式訂購結果，您爲什麼還要依賴無證的意外後果？有很多方法可能會崩潰，我不能推薦任何人使用這些技術。 –

準確地說。我的觀點是：開發服務器提供的證明「事情有效」的證據比無用的更糟糕。具有錯誤或缺少'ORDER BY'代碼的應用程序可能在小型開發服務器上正常工作，並在移至生產環境時崩潰。更糟糕的是，當某個表跨越大小閾值時，它可能會在一年內崩潰。我見過兩個。「有時，但並非總是」，也被稱爲「不可預知的」，是一個在實踐中需要掌握的硬性概念。 –

正確的結果，但在SQL

回答

相關問題