問題タブ [inline-view]

マスター、子、孫として3つのテーブルがあります。このような単純化されたもの：

より大きなクエリでは、これら 3 つのテーブルを次のようなインライン ビューに結合します。

私の問題は、where 句で参照する time_stamp を指定しなかったことです。驚いたことに、エラーは発生しませんでしたが、代わりにデータベースは列 table1.time_stamp を使用することにしました! 私の最初の質問は、「ORA-00918: 列があいまいに定義されています」というメッセージが表示されない理由があるのですか? 問題を見つけるのに少し時間がかかりましたが、見つけたら、インラインビューの選択で、この場合tbl3.time_stampで興味のある列を指定することで簡単に修正できました。テスト時に、列リストに time_stamp を 2 つ含めると、予想どおり ORA-00918 が発生することがわかりました。

助けてください。ここで何か不足していますか、それとも Oracle 11 のインライン ビューに問題 (バグまたは機能) がありますか?

私はOracle SQLを学んでおり、次のようなテーブルがあります。

上の表は、クエリで作成したインライン ビューを表しています。ご覧のとおり、テーブルは名前と国でグループ化され、いくつかのカウントを行っています。カウント列を使用してテーブルをフィルタリングし、次のようにします。

ご覧のとおり、名前ごとに、カウントに基づいて国を選択したいと考えています。

これは非常に単純なクエリのように見えますが、明らかな何かが欠けているに違いありません。このシナリオはかなり一般的だと思います。

製品を格納するテーブルと、トランザクションを格納する別のテーブルがあります。transaction テーブルには、セールスマンに関する情報が含まれています。ここで、すべての製品をリストし、この製品を最後に販売したセールスマンの ID を含むレポートを作成する必要があります。

次のような簡単なクエリを試しました。

select id, product_name, (select salesman_id from (select salesman_id from trans where product_id = a.id order by trans_date desc) where rownum = 1) salesman_id from products a

このクエリにより、a.id で無効な識別子が返されました。

ネットを検索した後、LATERAL句を追加しようとしました。次のように

select id, product_name, salesman_id from products a, LATERAL(select salesman_id from (select salesman_id from trans where product_id = a.id order by trans_date desc) where rownum = 1)

しかし、このクエリでは不完全な SQL ステートメントが返されます。

単一のクエリでこれを達成する簡単な方法はありますか?

"FROM" 句で定義されたインライン ビューを WHERE 句のサブクエリから参照することはできますか?

この例では、すべての教師をリストしようとしています。それぞれの教師について、出席学生の最大平均 (すべてのレッスンで計算) を持つコースを表示したいと考えています。インラインビュー(tmp)を使って科目ごとの平均出席者数を計算してみたのですが、サブクエリのSELECT max(...)でそのビューを参照できるかわかりません。Oracle で動作させるにはこれが必要ですが、残念ながら現時点ではそれを試すための Oracle データベースがありません。MySQL で試してみました (Oracle 固有の機能を使用しているとは思わないため) が、予想どおり、「テーブル 'db.tmp' が存在しません」というエラーが表示されます。これはOracleで何とか可能ですか？

これが私のスキーマの例です：

(下手な英語でごめんなさい)

このクエリをインライン ビューで再構築するのを手伝ってくれる人はいますか?

サンプル

Django ORM を使用して、次の (Postgres) SQL ステートメントを表現しようとしています。

問題は、FROM 句 (「インライン ビュー」とも呼ばれる) でサブクエリを使用していることです。

使用してみまし.extra(tables=['...'])たが、Django はステートメントに引用符を追加し、SQL を無効にします。

.rawクエリに頼らないほうがいいです。これを行う方法はありますか？コア API で方法が提供されない場合は、再利用可能なアプリを使用することもできます。

編集：

これは、結合を使用した (一見) 同等のステートメントです。

約 3 倍遅くなりますが、Django 1.9 ORM メソッドを使用してこれを記述することは可能です。

11/2更新

追加のトラブルシューティングを行った後、私のチームは、この Oracle のバグを12c、クエリが機能しなくなる前夜にデータベースで行われたパラメーターの変更に直接関連付けることができました。このデータベースに関連付けられたアプリケーションでパフォーマンスの問題が発生した後、私のチームは DBA にOPTIMIZER_FEATURES_ENABLEパラメータを から12.1.02に変更してもらいました11.2.0.4。これにより、問題のアプリケーションのパフォーマンスの問題は修正されましたが、上記のバグが発生しました。確認のために、このパラメーターを変更することで、別の環境で同じ問題を再現できました。私の DBA は、これを確認するために Oracle にチケットを提出しました。

回避策として、期待される結果を取得するためにクエリを少し変更することができました。具体的には、Subquery1withを組み合わせてSubquery2、いくつかの述語を句から the Subquery1(より適切に属する場所) に移動しました。この変更により、実行計画が編集されました (以前にリストされたものよりも効率がわずかに低下します) が、元の問題に対処するには十分でした。WHEREJOIN

元の投稿

まず、この質問が曖昧であることをお詫びしますが、機密の金融システムを扱っているため、特定の実装の詳細を非表示にする必要があります。

バックグラウンド

Oracleかなり前に本番環境に投入したクエリがありますが、最近、 から11gへのアップグレード後に予期した結果が偶然に生成されなくなりました12c。私 (および私のプロダクション サポート チーム) の知る限り、このクエリはその 1 年以上前から問題なく機能していました。

詳細

クエリは非常に複雑であまり効率的ではありませんが、これは主に、正規化されていないテーブル (歴史的にメインフレームをモデルにしたもの) と上流システムからの不十分なデータ入力を扱っているためです。複雑なビジネス状況に対処するために、複数レベルのサブクエリ ファクタリング (WITHステートメント) を活用し、最終的なステートメントで 2 つのインライン ビューを結合しました。複雑な述語をすべて除いたクエリの基本構造は次のとおりです。

私は3つのテーブルを持っていますTable1, Table2, Table3. Table1からのレコードで構成される処理テーブルTable2です。

最後のクエリは非常に基本的なものです。

問題

最後のクエリを編集して 2 番目のインライン ビューを削除し、インライン ビューの出力を評価すると、返された行Aが0 になります。個々のサブクエリのレコードを手動で評価したところ、これが予期された結果であることを確認できました。

同様に、最後のクエリを編集して「B」インライン ビューのみの出力を生成すると、6 つの行が返されます。繰り返しますが、手動でデータを評価しましたが、これはまさに期待どおりです。

これら 2 つのサブセット (Inline ViewAと Inline View B) を結合すると、最終的なクエリ結果は 0 行になると予想されます (完全なセットと空のセットの間の内部結合では一致が生成されないため)。ただし、上記のように内部結合を使用してクエリ全体を実行すると、1158 行が返されます。

実行計画を確認しましたが、何も思い浮かびません:

質問

明らかに、私は Oracle Optimizer を混乱させるために何かを行っており、更新されたクエリ プランは、送信したものとはかなり異なるクエリを引き戻しています。私の最善の推測では、これらの一時的なビューがすべて同じクエリ内に浮かんでいるため、Oracle を混乱させて、依存するセットの前にいくつかのセットを評価してしまったのです。

今日に至るまで、このWITHステートメントに関する公式の Oracle ドキュメントを見つけることができなかったので、サブクエリが評価される順序について完全に確信を持ったことはありませんでした。SO の検索で気付きました (今は見つかりません) 誰かが、因数分解されたサブクエリは別の因数分解されたクエリを参照できないと述べました。これが本当だとは今まで知らなかったのですが、上記の奇妙な出力を見ると、このクエリで運が良かったのではないかと思います。

誰かが私が見ている動作を説明できますか? このクエリ プランで明らかに間違ったことをしようとしていますか? または、11g と 12c の間で何かが変更され、このクエリの動作が変更された理由を説明できる可能性はありますか?

昔、遠く離れたデータベースで、ある開発者が述語の記述順序に依存するクエリを作成しました。

例えば、

(計画の説明は、to_number変換が に適用されることを示唆していますa.char_column)

これは「うまくいく」（Oracle 11g）というよりも、偶然だと思います。ただし、Oracle 12c で実行する場合、述語の順序は守られないため、このクエリは無効な数値の例外で中断されます。ORDERED_PREDICATES次のようにヒントを使用して、12cに述語を順番に評価させようとすることができることを認識しています

.. またはto_char、比較に使用する値の 1 つをキャストします。欠点は、to_charたとえば100万行で動作する可能性があることです。次のインラインビューがおそらくより良い解決策だと思います。インライン ビューが最初に評価されることは保証されていますか?