WHERE 1=1

本当にリソースない組み込みやってるけどこれの知識は役に立つ時も富豪的すぎて役に立たない時もある

>WHERE 1=1
可変するかもなー…ってときあるとほんとに便利

ウィンドウ関数が分からん…
意味は分かるけどいつ使ったらいいの？

なんで一番下のレコード取れないんだよ
なんで最頻値取れないんだよ

>なんで一番下のレコード取れないんだよ
>なんで最頻値取れないんだよ
取れるよ？

なんか遅いからインデックスつけようぜ！

>ウィンドウ関数が分からん…
>意味は分かるけどいつ使ったらいいの？
テストの結果に偏差値をつけるときとか？

>ウィンドウ関数が分からん…
>意味は分かるけどいつ使ったらいいの？
月の累計値取りたいときとか

計算関係はできればロジックのほうに置いておきたいぜー！
ってとこと
なんでもSQLにやらせようぜー！
ってとこがあるからまあ

whereで指定する順番って意味あるよね？

>whereで指定する順番って意味あるよね？
魚って海に生えてるよねみたいなこと言われても困る…

>whereで指定する順番って意味あるよね？
これでいいのかな…不安だから括弧で囲むぜー！

>ウィンドウ関数が分からん…
>意味は分かるけどいつ使ったらいいの？
集計をSQLだけでしたいとき

PLSQLできること多過ぎる

>whereで指定する順番って意味あるよね？
順番に処理されるからあるはずだが…
速くて絞れるやつから書こうねえ

先人が作ったこってりしたSQL
数年後そこには性能改善するはめになる後継者の姿が

>自分が作ったこってりしたSQL
>数年後そこには性能改善するはめになる自分の姿が

REGEXP使っていい？

SQLが複数回走るのは悪！一回で取るべし！って現場のJOINの数が多くて読むのが楽しかった
ただアプリのパフォーマンス悪かった

弊社も高いOracleDatabaseから撤退しようと思うから「」君協力してくれ

SQLこってりするのはまだいい
テーブル設計がこってりしてると…

SQLでなんでもできるぜーってのは分からんでもないけど
千行超える奴ばっかりなのは止めてくれ

こってりしたテーブル設計…？
なんか…どう考えてもこれ３つくらいに分割できるだろみたいな複数要素の塊みたいな？

>whereで指定する順番って意味あるよね？
オプティマイザ君がいい感じにしてくれるから意識しなくてヨシ！

なんだこの明らかに冗長なSQLは
俺様がきれいにしてやろう
…同じ結果にならない

>オプティマイザ君がいい感じにしてくれるから意識しなくてヨシ！
やめろそれはどんどん積み重なるやつだ！

SQLよくわからないから全部取ってきてアプリ側で処理するぜ

索引使ってくれないかもしれないしちゃんとしよう

>SQLよくわからないから全部取ってきてアプリ側で処理するぜ
量が少なければそれでいいと思う

SQLiteでも使える文が正義

１万件くらいなら何にも気にしなくていいよね

何秒までなら許せる？

>SQLよくわからないから全部取ってきてアプリ側で処理するぜ
変に同じテーブルを結合しまくるよりこっちの方が見やすいんだよな…

>何秒までなら許せる？
ユーザのレスポンスに直結するなら詰められるだけ詰めたい…なぜなら俺ならイライラするから…

そんな事より見てくれよ俺が書いた1万行以上あるCREATE VIEW！

多重viewはやめろ　やめろ

ロック周りが何もわからない
ギャップロックって何なんだよ

>弊社も高いOracleDatabaseから撤退しようと思うから「」君協力してくれ
PLSQLゴリゴリにしたコード資産がたっぷりあるのなら無理としか
変に移植するよりお金払ってでもそのままのほうが安い

数値計算はSQLの方が精度高いしめちゃ早いし
俺は四則演算ならSQLに計算させる派

インデックスが何もわからない
b木ってなんですか？

集計処理SQL以外でしたくないマン

1回目は時間かかったけど2回目はすぐ終わるからヨシ！

>集計処理SQL以外でしたくないマン
取り出して外で書いた方が楽じゃね…

主キーで絞って取得してもなお遅いクエリはもう取得数を絞るしか早くなる余地ないんですかね？

集計処理SQL以外のやり方がわからないマン

>集計処理SQL以外でしたくないマン
pythonのpandasライブラリでクエリライクにデータ集計できるけど取っ掛かりでつまづいて
もうDBでやらせてほしいとなった

>主キーで絞って取得してもなお遅いクエリはもう取得数を絞るしか早くなる余地ないんですかね？
インデックスはって必要なカラムだけとって結合見直してDB自体のチューニングしてダメならクエリそのものを分割するしかなくない？

サポート切れでバージョンアップすると旧来のSQLがゴミカスな性能になっててウケる
ヒント句でバージョン指定するか…

正直人の書いたSQLが一見してもさっぱり読めない
IPAの試験ですごく苦戦した

>>主キーで絞って取得してもなお遅いクエリはもう取得数を絞るしか早くなる余地ないんですかね？
>インデックスはって必要なカラムだけとって結合見直してDB自体のチューニングしてダメならクエリそのものを分割するしかなくない？
まだ設計段階からデータ型が不適切である可能性が残ってるぜー！

なんでこんなものが使われてるのだろうと常々不思議に思ってる

>なんでこんなものが使われてるのだろうと常々不思議に思ってる
代替ある？

SQLは言語の中では比較的簡単な方

昔はクエリ自分でかけたけどもう無理だわ
ビルダー使わないとプログラム的にキモい感じがする

DBによって色々違う部分が多すぎる
ずっとMySQLで生きてきたけど他のDB使える気がしない

>正直人の書いたSQLが一見してもさっぱり読めない
>IPAの試験ですごく苦戦した
俺は業務で何百ステップもあるようなクエリを何度も見てきたから
Oracle語や関数が使われてるでもなければ何とかなるかな

全部A.HOGE=B.HOGE(+)でいいじゃんね

>DBによって色々違う部分が多すぎる
>ずっとMySQLで生きてきたけど他のDB使える気がしない
Oracleしかまともに使ったことないから標準SQLの書き方忘れた…

だましてわるかった
PL/SQLはSQLじゃない

>なんでこんなものが使われてるのだろうと常々不思議に思ってる
実質主キー設定できないsalesforceは好きか？

とりあえずミックの本を読め

UNIONとかEXISTSとかいつ使うんだよーと思ってたが
仕事で頻繁に使うわ

クエリこそもうAI丸投げでいいだろと思う

SQLのverが古くてサブクエリー地獄だらけのSQL文観た時はverアップしてくだち！！って本当どなりそうになった

何でこのプロシージャ何度も呼ぶ必要あるんすか

>なんか遅いからインデックスつけようぜ！
インデックスまみれになってさらに遅くなる…

group by cubeってなんだ

FROM,WHERE,SELECTの順で書かせてくだち　

tmpテーブル

>FROM,WHERE,SELECTの順で書かせてくだち　
ないわー

しゃあっ
SELECT *

orマッパーと仲良くなれない…
sql文書かせてくだち！

NoSQLだのNewSQLだのOODBだのグラフクエリ言語だのあるけど
SQLでいいかなって…！

ORマッパーって知らないんですかﾌﾟﾌﾟ
って言い出していた上司がパフォーマンス出ないんですけお！って地獄になっているのみていい気持ちになった

SELECTが文頭じゃなくなったら何取り出そうとしてるのかすらわからなくなるんだろ
冗談じゃねえ…

>FROM,WHERE,SELECTの順で書かせてくだち　
入力補完あるエディタ使ってるけどこれ
SELECTで指定する項目をfromから取ってくるから取り敢えずfromから書くとかになる

取得データを上から番号振る機能はデフォルトで付けて欲しいわ

PHPでセレクトクエリの結果受けとるの楽ね
C#で結果受け取り様にわざわざクラス定義してた

業務アプリだとupdateやinsert使う時はSQL以外の事考慮しないといけないのがお辛い…

DAOにするだお

>取得データを上から番号振る機能はデフォルトで付けて欲しいわ
うん…？
結果セットのいくつめ取り出すとかじゃなくてROWナンバー最初からつけるってこと？

rest api作る時どうやってトランザクションしていいのかわからなくて詰んだ

>C#で結果受け取り様にわざわざクラス定義してた
タプル…

>変に移植するよりお金払ってでもそのままのほうが安い
そう思って先延ばしにするとどんどん値上がりするんだ
損益分岐点簡単に突破するよ

>FROM,WHERE,SELECTの順で書かせてくだち　
日本語の文章に置き換えて考える時はこういう順番の方がやりやすそうなのは分かる

我慢と節約と古いものを大事にするのは日本の美徳だからな…

いやだ〜結果受ける時クラス定義していないと
何入って着たのか分かりづらいよ

どこから取ってるかより何を取ってるかのほうが優先度高いから…

SELECTが最初なのはStructured English Query Languageとして生まれた名残
クエリが複雑になるほど弊害が出てくる！

FROM WHERE GROUP BY HAVING SELECT ORDER BYの順で書くなあ

FROM先頭とか最悪何してるかの判定から始まるじゃん

もう良くわかんないから
オラクルハカセみたいな同僚に頼む

CTE？with？で簡単な処理単位でクエリ区切るのたのちい！！

実行順で書きたくなることはある

GROUP BYあたりから分かってない人増える

ChatGPTがいい感じにパフォーマンスの改善案提案してくれたりしないの

havingとかunionとか何に使うのかよくわからないやつ

ロジック側でどうこうするの書くのだるいし
SQL文渡したらDBで処理するかロジックで処理するかを上手く判断して最適化するライブラリあればいいんじゃないか？

>ロック周りが何もわからない
>ギャップロックって何なんだよ
俺もふんわりした気持ちでしか分かってないけど
ロックの空振りはまずいって認識だぜ！

>ChatGPTがいい感じにパフォーマンスの改善案提案してくれたりしないの
前提と質問がしっかりしてれば提案もちゃんと出てくるとは思うが
でも実装コスト払えるかな…

>havingとかunionとか何に使うのかよくわからないやつ
そこは使うだろ…

selectが一番上なのは妥当じゃないの
書くときはともかく読むときは何が出力されるのかが上のほうがいい

mysql使いだからwindow関数とか知らんし…
って思っていたら8.0から入りやがった

>selectが一番上なのは妥当じゃないの
>書くときはともかく読むときは何が出力されるのかが上のほうがいい
参照系なのか更新系なのかは最初に分かりたいよな

>SELECTで指定する項目をfromから取ってくるから取り敢えずselectは*で書くとかになる

コマンドもカラム名も両方小文字で書かれると見にくくてキレそう

パーティショニングは全てを解決する

>selectが一番上なのは妥当じゃないの
>書くときはともかく読むときは何が出力されるのかが上のほうがいい
つまりさ
FROMからとか好きな順番で書いたら同じ出力結果で読みやすくなるように整形してくれるツールがあればいいんじゃないかな？

with句のせいでSELECTが見えねえ

>REGEXP使っていい？
インデックス効かないからダメ

>havingとかunionとか何に使うのかよくわからないやつ
unionはテーブルが違うけど意味的に近いものをまとめることができる
業務だと勘定系のテーブルがいくつか種類分かれてる場合に共通した意味の項目をまとめて取りたいときとか

仕事で水平分割されたDBの統合を検証したけど死ぬかと思った
結局AWS側のバグで失敗するし

>with句のせいでSELECTが見えねえ
使わんかったら同じサブクエリを途中で何回も挟まなければいけねェ…
必要な犠牲だ…

partitionとrankの使い方がいまだにわからん
1回頑張って使ってけど

select書くときは入力補完でカラム指定するからfromから書くけど
入力位置が前後するのが面倒いってのは分かる

chatgptに投げたらお手軽にSQL作ってくれるぜー
この関数使えないんですけお

>>selectが一番上なのは妥当じゃないの
>>書くときはともかく読むときは何が出力されるのかが上のほうがいい
>つまりさ
>FROMからとか好きな順番で書いたら同じ出力結果で読みやすくなるように整形してくれるツールがあればいいんじゃないかな？
探せばある気がする

>partitionとrankの使い方がいまだにわからん
>1回頑張って使ってけど
行ごとに1個下の行の項目参照させたいとかに便利

>行ごとに1個下の行の項目参照させたいとかに便利
碌でもないテーブルの予感…

自分でケツ拭けない書き換えなんてやめたまえ
拭けるなら最初からそう書こう

GoogleスプシのQUERY関数いいよね…

Symfowareってよく分からんRDBを仕事で触ってる
よく分からん…

>行ごとに1個下の行の項目参照させたいとかに便利
そういえば使った時はデータをツリー状にしたの思い出した
複雑なクエリにならざるを得ないのか

>Symfowareってよく分からんRDBを仕事で触ってる
富士通のは官公庁とかでまだ結構残ってそう

>Symfowareってよく分からんRDBを仕事で触ってる
>よく分からん…
おっ富士通だな
死んでくれ

>partitionとrankの使い方がいまだにわからん
>1回頑張って使ってけど
一番よく使ってたのはある項目を並べ替えて1番になる値を持つ行の項目を参照させたいとかだった

なんでそんなパッと出てくるんだ

ふふ…チューニングと言われても全然分からんから適当に誤魔化そう

>なんでそんなパッと出てくるんだ
死んでほしいやつ筆頭だから
本当はOracleも同じぐらい死んでほしい

もう全部sqliteになってくれ

>ふふ…チューニングと言われても全然分からんから適当に誤魔化そう
最初インデックスを全く貼らずに
後日パフォーマンスチューニングでインデックス貼るのが
出来るエンジニアスタイルだ

>ふふ…チューニングと言われても全然分からんから適当に誤魔化そう
実行計画見よ…読み方がわからない！

>もう全部sqliteになってくれ
それは大分困る
サーバー間の同期をどうしろと

シンフォウェアをシンフォギアと仕事中に言い間違えて恥ずかしい思いをしたって「」が昔いたな

>もう全部sqliteになってくれ
それ有用なの組み込みくらいだろ

昔巨大書店でsymfowareの専門書見つけて
やったー貴重な技術書だーって手に取ったら
symfowareの歴史について書かれた本だった
出版すんな

「Where カラム名 in (Select ○○…)」みたいな感じでWhere句内でサブクエリ噛ませてるクエリAに対し他のテーブルBから追加したいカラムがあったから結合しようとしたらエラー吐かれた
おのれAccess…！

>symfowareの歴史について書かれた本だった
酷すぎる

>実行計画見よ…改善が必要だわ…直し方がわからない！

富士通にも優秀な人はたくさんいるんだろうけど
そういう人は東証とか担当していて下界には降りてこない

ヒントを適切に使いたい
あとOracleの変な関数を使いこなしたい…使う場所ないけど

>もう全部postgresqlになってくれ

AWS Auroraにしたら割と解決した
あいつ速いぜ

exists使わせろ

オ…オデ EXISTSワカラナイ…IN句ツカウ

エクセルの関数覚えるの大変だからVBAでSQL使って操作するね…

MySQL(MariaDB)

existsは新人研修で習ったけど使うべき場面でパッと出てこないままここまで来てしまった

複数のテーブル元に判定や取得するときビューなり結合なり駆使してSQL一発でデータ抜いた方がいいんだろうけどついアプリケーション側で判定したくなる

left joinとinner joinの使い分けを未だに直感でやってるぜー

>複数のテーブル元に判定や取得するときビューなり結合なり駆使してSQL一発でデータ抜いた方がいいんだろうけどついアプリケーション側で判定したくなる
あとで直せばいいだろ…

>left joinとinner joinの使い分けを未だに直感でやってるぜー
死罪

>left joinとinner joinの使い分けを未だに直感でやってるぜー
出力データが大きく変わってくるのにそこを直感…？

order by付けない人の爪全部剥がしたい

>existsは新人研修で習ったけど使うべき場面でパッと出てこないままここまで来てしまった
参照先のテーブル行が数百数千万単位になると…

RIGHT JOINをいつ使うのか真剣に分からない
趣味で作ったのか？

色んな関数や構文駆使すればSQLだけで結構なことできるんだろうけど出来上がったSQLは自分でも読みたくなくなる

エンジニア人生で今まで一度しかright join使ったことない

>>left joinとinner joinの使い分けを未だに直感でやってるぜー
>出力データが大きく変わってくるのにそこを直感…？
実際システムに組み込んでるんじゃなくてデータ探すときに使ってるだけだから……

>order by付けない人の爪全部剥がしたい
順序いらんし…

付け焼き刃の修正用なんじゃないかright

>>order by付けない人の爪全部剥がしたい
>順序いらんし…
並び替えもタダじゃないからな…

ORDER BY の指定で数字使ってるのこないだ入った案件で初めて見た

>>order by付けない人の爪全部剥がしたい
>順序いらんし…
テスト前後のDBダンプで並び順変わってて差分出るとくそあ！！！ってなる

生SQL組んでからORMで再現しないとよくわからない

弊社のクエリ得意な人は昔の技術オタク気質というか一言多い人多くてとても聞きづらい
なんでいちいちトゲトゲしいの…

>existsは新人研修で習ったけど使うべき場面でパッと出てこないままここまで来てしまった
状況自体は普通にあるでしょ
特定のデータが1件以上あるか0件かで分岐したいときに使うだけだし

この前初めてCROSS JOIN使ってちょっと感動した

leftとかinnerとかなんか直観的じゃない言葉だよね

>生SQL組んでからORMで再現しないとよくわからない
ORマッパーってSQLにアレルギーない人には逆にまどろっこしいんだよな…

高速化にまつわる小手先のテクニックは数多あるけどオプティマイザﾘﾆﾝｻﾝを信じてもう深く気にしないことにした

排他制御が何もわからない
けど最近よくデッドロック起こるからなんとかしないと…

すごい複雑な処理を書ける人より
可読性高いインデントやコメントつけてくれる人の方が
ぼくは好きです

>生SQL組んでからORMで再現しないとよくわからない
というかテメエが作ったSQLをいったんどっかに吐いてくれねえかってなるORマッパー

JOINは結合の仕方が勝手に決まるの面倒なんだよ

>ORDER BY の指定で数字使ってるのこないだ入った案件で初めて見た
俺も俺も
そんなことできるのもすっかり忘れてた

結合とかその辺はもうパワークエリでやるようになっちゃった

>leftとかinnerとかなんか直観的じゃない言葉だよね
それは一回ちゃんと勉強したほうがいいぞleft innerなんて超直感的じゃん

CROSS JOINがわからないは許す
俺もわからない

以前EXISTS使おうとしたら読みにくいからINNER JOINでいいじゃんって言われて早さが違うって返したかったけどまあ数万件程度じゃ大して変わんないんのは確かなんだよなー

full outer joinいいよね

imgエンジニア勉強会は休日でもなんか見入っちゃう

>排他制御が何もわからない
>けど最近よくデッドロック起こるからなんとかしないと…
なんか…並列処理諦めたほうがよさそうな案件だな…

>それは一回ちゃんと勉強したほうがいいぞleft innerなんて超直感的じゃん
俺はそうじゃないからどうだろ

webシステムだと排他制御からは逃げられんぞ
アプリ側で制御できるならいいけどさ

SELECTで*使うなでもカラムの省略は許さんテーブルの修飾も必ずつけろ
って謎ルールに出くわしたことがある
なんでも「その方が早い」んだと

>full outer joinいいよね
必要になってシステムで組み込んだこと一回だけある
結合するテーブルの両方が等価でどっちも欠けることが有る奴を結合するとき

どうせ大した件数じゃねえんだからもうマッパーでいいだろと思うことがたびたび

>以前EXISTS使おうとしたら読みにくいからINNER JOINでいいじゃんって言われて早さが違うって返したかったけどまあ数万件程度じゃ大して変わんないんのは確かなんだよなー
INNER JOINの方が早いという意見もあってもうわからん…

>SELECTで*使うなでもカラムの省略は許さんテーブルの修飾も必ずつけろ
>って謎ルールに出くわしたことがある
>なんでも「その方が早い」んだと
昔はそうだったんだろうけど今はオプティマイザがいい感じにしてくれるんじゃねえの…？

>SELECTで*使うなでもカラムの省略は許さんテーブルの修飾も必ずつけろ
>って謎ルールに出くわしたことがある
これどこでもやってるものだと思ってたけど違うんだ……

排他とかisolation levelは経験しないとむずいよね

確かにマッパー色々問題あるけどおじさんエンジニアは嫌いすぎてて変なマウントとってくるのが面倒くさい
こういう人が死滅するようにいいやつが出てきて欲しい

>なんでも「その方が早い」んだと
測定バトルしようぜ

>SELECTで*使うなでもカラムの省略は許さんテーブルの修飾も必ずつけろ
>って謎ルールに出くわしたことがある
>なんでも「その方が早い」んだと
昔のオプティマイザだとそんな感じだったようなことを読んだ気がする
今はまあ気にするほどじゃないんじゃないかな

>確かにマッパー色々問題あるけどおじさんエンジニアは嫌いすぎてて変なマウントとってくるのが面倒くさい
>こういう人が死滅するようにいいやつが出てきて欲しい
それはおじさんエンジニアだって望んでるんだ

>CROSS JOIN
from A inner join B on True
これでよし

そのうちAIが革新的なRDBMSつくってくれたりしないかな

今はオプティマイザかなり賢いから些細な記載方法で悩むより可読性優先していいよね…？