問題タブ [lateral-join]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
0 に答える
36 参照

sql - group by で使用すると cross apply の動作がおかしくなる

correctこの場合、列と列のincorrect値が異なる理由がわかりません。正直に言うと、これが有効な SQL であるというのは奇妙に思えcross applyますgroup by

結果は次のとおりです。

しかし、そのgroup by部分を削除して、次のように追加するとdistinct:

次の結果が得られます。

incorrectこれは、最初のクエリの列から期待した結果です。

節を使用する場合、group by節の扱いは異なりgroup byますか? 今までは、サブクエリとのよりインテリジェントな結合だとしか思っていませんでした。パーツに追加incorrectするとgroup by、最初のクエリの結果で説明されているような動作になります。コンパイルして実行し、多少ランダムな値を返します。

編集:DBバージョンはOracle Database 12c Enterprise Edition 12.1.0.2.0です

0 投票する
1 に答える
408 参照

postgresql - CROSS JOIN を「暗黙的に LATERAL」にすることはできますか?

次のかなり単純なデータベースを想定します。

したがって、次の表があります。

今、私は次のようなクエリを見てきました:

次の結果を返します。

私の問題は、ここで何が起こっているのか理解できないことです。一方では、これはLATERAL結合のように見えます。これは、 の右側が JOIN左側のものを参照し、結果が完全に論理的であるためです。一方、マニュアルには次のように書かれています。

( がないLATERAL場合、各サブは個別に評価されるため、他の項目SELECTを相互参照できません。)FROM

この:

列のソース テーブルは、アイテムに結合されているINNERか、LEFT結合されている必要がありLATERAL ます […]

(こちらを参照)、もちろん、n × mCROSS JOINは返されません(このページに記載されているように)。

私の質問は: 上記のクエリの結果はマニュアルと矛盾していませんか? そうでない場合、それJSONB_EACHはどういうわけか特別に扱われているということですか? (それは私が驚くべきことだと思います。)

0 投票する
2 に答える
327 参照

sql - PostgreSQL は、国テーブルに対して配列内の国を解析します

コンテンツと国のテーブルがあります。 Countryは非常に単純です: 文字列として定義された country_name 列: アルバニア、ベルギー、中国、デンマークなど...

コンテンツは、さまざまなデータを含む 50 万行のテーブルで、countries 列は配列 text[] として定義されています。そこにある各値には、{"デンマーク、フィンランド、フランス、ドイツ、アイルランド、イギリス、イタリア、オランダ、ポーランド、ロシア、スペイン、スウェーデン、オーストラリア、ブラジル、カナダ、中国、インド、インドネシア、日本のように連結されたいくつかの国があります。 ,マレーシア,ベトナム,メキシコ,"韓国",タイ,アメリカ,シンガポール,アラブ首長国連邦"}

社内チームからの更新は数千件のレコードに関するものであり、すべての国のスペルが正しいかどうかはわかりません。したがって、タスクは、country テーブルの country_name と照合することです。

私はreplace(replace(country_array::text,'{',''),'}','') as country_textUNPIVOTを実行して、国のテーブルに対して各列をチェックすることを考えています。Content テーブルのcountries 配列に、country テーブルの有効な国名があることを確認する簡単な方法はありますか?

ありがとうございました

0 投票する
1 に答える
72 参照

postgresql - Selecting random IDs from another table....confused about LATERAL JOIN

I'm trying to get a handle on generating random data in Postgres, and find I'm misunderstanding something about LATERAL JOIN. Building on some help I got earlier, I've got some code that's trying to:

-- Generate a series of numbers
-- Generate timestamps on the hour matching the number sequence
-- Generate a random(ish) score in a roughly normal distribution for each row
-- Pick an ID randomly from a table in the database.

This last bit is not working. When I run the script shown below, I get a random value for the facility_id, but every row has the same random value. I'd like the random ID assigned on each row, not once globally for the whole run. In procedural thinking, the facility_id is being assigned before the loop, and I want it assigned in the loop. I thought that LATERAL JOIN would help me out here, but

I thought that a subquery might work, but I also get a single value across all rows for the facility_id with this code:

I haven't listed the facility table definition, but the only field that matters above is id, so any table would work the same way.

In case it makes any difference to the answer, once I can figure out the solution to this problem, I'd like to then use the random facility_id on each row as an input to select something else out of another table.

Thanks for any help. I'm working on this not just to get the solution, but to try and get a better mental model of how the various tools work. I'm (obviously) not at the point where I can read code like the above and predict in my head how it will behave. Getting to that understanding is kind of fundamental to figuring out how to solve problems on my own. Put another way, I'm not only trying to solve this problem, I'm trying to reduce my mental gaps generally.

Premature Optimization

I'm editing my question as I need to post more code.

Ha! Glad to see I'm not the only one accused of having premature optimization problems ;-) That's something that can be hurled in anger in a design or review session, to be sure.

I think what you're showing is that the id is used in an expression, which makes its outcome indeterminate. And here's where I live and relearn that I I should post my table structure. Our id fields are UUIDs. I've attempted to hack together something that would use the UUID in an expression, but it does not change the behavior.

where left(id::text,1) <> 'X' -- prevent premature optimization

The premature optimization you describe, and the workaround to defeating it, are not behaviors I could predict. Because gaps. I've tried running my code with the left expression through explain (costs off), and I get this kind of output: