'Order By'句の列を要求するクエリは、 'Group by'句の列と一致します

Question

これは奇数のビットです。私は3つのテーブルを結合する次のクエリを実行しようとしています。

Select t3.id, t3.name, t3.phone_no, t1.reg_dtm, count(t1.reg_dtm) 
from tableA t1, tableB t2, tableC t3 
Where t1.id = t2.id 
And t2.id = t3.id 
Group by t3.id, t3.name, t3.phone_no, t1.reg_dtm 
Order by t2.id, t1.reg_dtm 

上記のクエリは、次のエラー

ORA-00979: not a GROUP BY expression 

を返しますが、GROUP BY句のすべてがORDER BY句であるように私はそれを変更した場合、それは動作します。

Select t3.id, t3.name, t3.phone_no, t1.reg_dtm, count(t1.reg_dtm) 
from tableA t1, tableB t2, tableC t3 
Where t1.id = t2.id 
And t2.id = t3.id 
Group by t3.id, t3.name, t3.phone_no, t1.reg_dtm 
Order by t3.id, t3.name, t3.phone_no, t1.reg_dtm 

この理由は正確ですか？

最初のクエリのステートメントに示されているt2.idがgroup byステートメントの一部ではないため、この問題が考えられます。これが原因なら、それはなぜ重要なのでしょうか？私は以前これを経験しておらず、グループと注文書との間に関係がないとは思わなかった。

私は上記のOracle 10GとMySQLをテストしました。事前に

おかげでORDER BY句は、SELECT文の中で他のすべての後に実行さ

Answer 1

実行します。 GROUPingシナリオでは、結果セットはデータの集計に使用される列に限定されます。最初の結果セットで指定された列がない場合、処理エンジンは要求された出力をどのように処理するのか理解しません。

つまり、クエリではt2.idとt1.idの値が異なるため（GROUP BY句では使用されていないため）、エンジンはその順序でデータを返すことができません。

Answer 2

結果セットにすべきではない、技術的GROUP BY節で言及されていない列（これらは集計していない限りは、すなわちmax(columnname)） - ので、どのようにそれはORDER BYそれらに意味をなすのでしょうか？言い換えれば、そのような質問はどういう意味ですか？

しかし、MySQL（私は他人についてはわかりません）では、GROUP BYに含まれていない列を選択することができます。なぜなら、奇妙なクエリ結果を得る理由を不思議に思う初心者のために多くの混乱を招くからです。

脇の下として、hereのように暗黙的な結合を避けることができます。

Answer 3

一般に、GROUP BY句には含まれておらず、結果を確定的にソートする方法がないため、SELECTリストには集計関数ではない列では注文できません。データベースは一般的に、最終結果にそのような列がどのように集約されるかを知らないため、結果の1つの行が、たとえばベース表の行を集計した結果である場合を処理する方法を知らない1 & 4の値を持ち、結果の別の行は、2 &の値を持つ実表の行を集計した結果です。3.いずれの方法でも結果をソートすることができない場合があります。あなたはすべての3つのテーブル間IDに内部結合をやっているので、

さて、この特定のケースでは、データベースは、理論的には、ORDER BY t2.id, t1.idが確定的に評価することができORDER BY t3.id, t3.idと意味的に等価であることを認識するために十分にスマートである可能性があります。しかし、このようなクエリ変換をオプティマイザに組み込んだデータベースは知られていません。そのような分析がうまくいかないときに導入される潜在的なバグのトレードオフは、実行しようとしているクエリーが、設定された理論の観点からあまり論理的に意味をなさないときに、それを含めることに反対する傾向があります。

Answer 4

select句に含まれる列でのみ注文することができます。したがって、order by t3.ud, t1.reg_dtmはそれを実行し、同じ意味を持ちます。

Answer 5

実際には、SQLを慎重に読み込むと、最初のステートメントではT3.IDでグループ化されますが、T2.IDでソートされます。

実行している実際のSQLの場合、唯一の問題は、誤植があることです。