なんでSQLってループ処理無いの?他言語と組み合わせないといけないって不便じゃね? [189442403]
■ このスレッドは過去ログ倉庫に格納されています
🧜🏾♂ ン ⛹🏿♀ 鮮 🧚🏼♂ タ 🏄♀ は 🙆🏽♂ 明 🧎♂ サ 🧏♂ 文 💂🏿♀
· 「SQLって何なの?
」「SQLはプログラミング言語とは違うの?
」 このような疑問に応えるべく、
SQLの基礎知識について解説します。
SQLについては何もわからない、
どういうときに使用するものなのかを知りたいという方から、
SQL文を実行して感触をつかんでみたいという方まで、
役立てて頂ける ...
統.一教会は.セッ.クスカルト.!
日本人の全財産.搾.取.&.性奴隷.化!
🤹🏿♀ 子 🙍🏼♀ サ 💂♂ タ 💆🏽♂ は 🧖♂ ン 🧖🏻♀ 鶴 🏃🏿♀ 韓 🙅🏾♂ Googleがなんか次世代っぽいの作ってくれるだろ あるが
なんならヒアドキュメントから動的にループ内容修正するような仮OOPもできるが 内部結合とか繰り返してると今どんなテーブルが出来上がってるか
だんだんわからなくなってくるが
自分の求めた結果が出てきたからヨシ!って現場猫感覚で仕事してる 最近BigQueryが流行ってきたせいかSQLできる人の求人増えてるのは実感する よく知らん新人だかが>>1のようなことを宣う場合
ほぼ100%根っこのところから勘違いしている
ほっとくと後々火事になるから
そいつから仕事取り上げてほかのことをさせるべき SQLから1件ずつレスポンスさせたら通信回数が増えてクソ重くなるぞ
だから配列で一括でレスポンスさせる
もうよく覚えてないけどプロシージャを学んだとき
えっ?処理系ってこれとSQL使えればあといらなくね?と感じた そもそもなんで色んな言語があるの?
統一言語作れないの?
物理学で言う統一理論みたいな >>8
SQLだけってのは厳しい
フルスタックなら余裕だぞ >>8
それとJavaとHTMLとJavascriptができたら一生食える プロシジャー込みでシステムつくったら
あとあと移植できないゴミになるだろうに
金持ち客をロックインさせたい側ならいらんとこでもプロシジャーで >>23
物理や数学は神の目で自然をみる
だから1+1は常に2だし、人間の都合で変えることはない
プログラミング、ITはそうじゃない
都合が悪けりゃかえればいい
今使われている技術も言語も
「見っかった手法のなかでは、今のところこれが一番良さそう」
と言うことで使われてるだけ >>26
Javaは得意です
フロントはHTMLやCSSの常識レベルしかやったことない
JSはフレームワーク多すぎ移り変わり激しすぎで真面目にやる気にならない >>19
もっと上やけど今年からexcel初めて触って、
今はバッチとかパワーシェルでちょっとした管理の真似事やってるよ
パソコンがどう動いてるか分かればある程度は見えてくる SQLを書こうと思う😌
テーブル10個ぐらいjoinすればええんやろ?😠 >>31
SQLもしらん奴がいうjavaができるとか高が知れてるんだわ >>31
APIサーバーとかをゼロから商用運用まで構築できる? そういう手続き型っぽい発想じゃないし、むしろついていたら不自然な気がする。
集合演算を言語にしたって感じだし >>31
それなら余裕じゃん
フロントは業務通じて覚えればいいしバックエンドできるって言ったらとりあえず中小ならどこでも受かると思う >>23
実質的にはC/C++が統一言語と言える
でも手間かかって場合によっては複雑で難しい上に互換性の問題にもぶち当たりやすい そもそも指定したものを一覧で持ってくるからループみたいなもんな気がする
だからSQLは間違えたことすると指数関数的に負荷が増えていく >>36
今どきAPIなんてflaskとかspringboot使って小学生でも作れるもんでなかったやろか?🤔 >>8
SQL極めるって簡単に言うけど
現場によってはJAVA嫌いで何するにもPL/SQL使いたがるプロマネが居たりで大変だぞ >>31
jsはフレームワークというかライブラリ周りが色々変わるけど、ベースのjsはずっと使われてるのでjsだけ極めれば問題ない。ただしES○○の新構文は覚える必要あるけど。 >>41
それは大抵の仕事はそうだろ
もっともそんな小学生はレアだけどな というか、色々やり方を検討しないでなんでも一つのツールとか言語でやりたがるやついるんだろうな。
自然言語じゃないんだから、プログラミング言語なんて新しいの覚えるのそこまでコストじゃないのに >>31
reactってやつにmaterial UIって奴のサンプルで簡単にそれらしいもんできるんよ😰 >>45
いやコストだろ
新しい言語でちゃんとしたコードレビュー通るようなコードかけるようになるまではそれなりに時間かかるだろ
趣味レベルの話なら知らん あと36だと正直厳しい、32なら大丈夫だった
今無職なら最初から大きい現場には放り込まれないから、それなりの経験積むと40越えちゃう
そこまで我慢できるかな >>23
みんなcommon lisp使えばいいよな >>48
半年も勉強すれば業務で使えるようになるよ。周りもだいたいそんなもんだし。 >>49
日本の平均年齢50歳だし40でも下っ端出来る社会になって欲しいわ 36の未経験PG職なんてよほどのことがない限り呼ばれない 無駄に好奇心高くて頻繁に言語やフレームワークを変える奴の魅力
後始末担当に気をつけて歩けよ >>45
まともに運用したことないだろアプデ地獄、EOLで発狂するぞ >>52
半年くらいのスパンならまだわかる
もっと短い期間を想定してたわ そういえばNoSQLとかそんなの一時期流行ってたけど
あっち方面はどうなったの? >>54
未経験だとバーターで大人数な現場にねじ込んで貰うしか無いよね
それでも20代前半と同じだけ貰えるかというと、難しいかな BigQueryのループ構文使って閉包テーブルの更新クエリとか書いたよ >>13
適当にやってると処理速度がとんでもなく遅いときあるよね >>54
ガチな無能経験者みたことあるけど考え方変わるわ
有能なら割りと年はそこまで関係ない
要は理解力や読解力とかの基礎学力のはなし
マジで勉強できない奴は物覚えも悪いし
なにかを管理するってのが出来ない
そういうのはマジで何年経験しようと素人と同レベル >>57
コスト低いというのは自然言語とくらべてって感じですね。まあ書いてはみたけど、さすがに
新しい言語を使うのはそれなりにコスト高いからね。ただ意地でも一つのツールしか使わない人はさすがにみたいな
感じで。 >>58
アメリカの新規のWEB開発ではもう主流レベル
開発スピードが圧倒的に速い
日本はそもそも使える人が少ないし遅れまくってる >>64
気持ちは解るんだが、有能無経験者って評価基準が無いから取るがわとしては運でしか無いんよ
君は業務経歴書が真っ白な人を取る? エアプだけどSQLを直接を手動で操作することなんてないんじゃないの? >>58
基本はNoSQLでRDBが必須の場合だけ使う感じ
DynamoDBが便利すぎる安いし みんなが業務で使ってるDBサーバのスペック教えて
RDBMS
OS
CPU数とコア数
MEM容量
StrageのランダムIO 新規にやるならもうBigtableとかのがいいんちゃうんけ 直積作って枝刈りしていくのが基本って凄まじいモデルだよな
まあ大半のエンジニアはそういう縛りプレイが嫌いじゃないだろうけど
中には絶対まともに書けない奴もいるよな たまに企業が起こす大事故は
手動に似たことをやらかしたと思われるw with clauseでrecursiveに書けるぞ >>66
あそこはそもそも作業者の知識レベルが違うからな
こっちの人間が全員ド素人に見えるレベル プロになって頭が切り替わったのはSQLだな
分岐とかループとか無しで結果の一覧を取り出す思考力
ノイマン型プログラミングと違う >>68
いまだに運用端末()に複数集まってヨシしてる現場あるぞ
せめて事前にレビュー済みのスクリプトにしとくとかそういう頭無いんだろうか SESでいける頂点の現場ってどこなん?
メルカリ?Yahoo? >>77
宣言型言語だからね
こうしろと命令する命令型と違ってこうあって欲しいと表現する
宣言型の言語は美しさがあるね >>23
F=maを統一理論から求めるのか?
そんな物理学者はいないよな
コンピューター言語も同じ decralativeって良いよね
なんか最適なpipelineを組むパズルみたいな面白さがあって
neural networkとかshader programmingとかもそういう趣がある データベースの実装って知らんけど内部ではループしてないの?
欲しいデータがあったら自前でピックアップするかDBに投げるかの違いじゃないんか >>86
複数の似たようなテーブルから取ってくる処理をSQLでループしたいけどできないのでJava側でループしてひたすら1つの配列に詰め直してるのは見た >>91
joinする際の実行計画てnested loopが選択されれば内部でfor文が動いとるんよ ストアドプロシージャはやめとけ
500行のプロシージャを触ったことがあるがメンテナンスが地獄だ >>91
select from テーブルでループします >>92
たしかにそういうのはSQL自体では実現不可能だなあ
テーブル名にLIKEみたいな曖昧な指定はできんからな >>91
それ君が気にすることじゃないよ
というと失礼だが、余程酷いDBや構文じゃなければ取ってくる速度は圧倒的に速い
あとDB使う一番の楽さは排他制御だと思う
なんかテーブルをトランケートして北海道に行くコピペ懐かしい SQLは関係モデルの式だから、ループがどうこうはそもそも理解が間違っている PHPとrubyとpythonが生きてるの嫌い
似たような言語だし淘汰されろよ >>23
おまえ科学ですらまともに学べずに学位論文誤魔化した分際で、毎日毎日統一理論の名前を出して
ほんと頭がバカな底辺教員丸出しだな >>103
言語仕様自体は宣言的だけど
実装は現在のCPUでは手続き的に内部記述するしかないし
言語仕様の外側の応用アプリ側も宣言的言語だけでは記述できないから
繰り返しの概念の翻訳とマッピングは必須
たとえばカーソル機能 >>104
PHPはもう終わってるだろ
PythonとRubyは同じ時期に違う概念で設計されたスクリプト言語だから適所適材で十分
頭が悪い人って道具毎の適性すら理解する事ができずに
なんでも一つの道具で片付く単純過ぎる世界観の下で生きているから世間とトラブルばかり起こすんだよな >>88
それ日本ですら1980年代に普及した概念だぞ
今まで40年間不勉強だった事が1発でバレる発言だな 普通のプログラムでも同じだよ
ある複数要素のデータの中から特定の条件に一致するデータだけ取り出すときの
単なる表面上の書き方の話 >>108
めっちゃ聴いてて草
よくある煽りに過剰反応しすぎだろ
結構言う割にはPHPの適材適所には触れずに終わってるって言っちゃうの可愛いねぇ この人の話は常に世間から20~30年遅れの話しかしないから哀れだわ
愚民だとバレて同情されているのに勝利宣言し出すから
学生からも排泄物のシミ扱いされてるだろ
哀れな精神異常職員だ プロシージャもしらない無能 これが日本の平均的な能力w PHPは20年近く前に一瞬使ったけど、頭の悪い人向けの言語で風前の灯だったな
設計が古すぎて20年弱前時点でもう誰もやりたがらないから、逆にレガシー技術者が重宝されるようなどうしようもない世界 >>111
その言語はおまえのように時代遅れで頭の弱い人物に仕事をやっているフリをさせるのに最適な言語だね
発展性が無いから無能な奴が余計な事に手を出して周りに迷惑をかけないように手枷足枷にするのに最適 インデックス貼るのめんどくさいからさあ
むしろデフォルトで全カラムにインデックス貼って、いらないやつを明示的に指摘するようにしてくれたほうが便利そうじゃない? RubyのMatzから見て同世代の底辺大職員、
Wikipediaの初代技術担当から見て少し歳上の元管理者が
こんなスレで30~40年遅れの初心者スキルの話を自慢げに書いてるのを見たら、大爆笑するだろうな
住んでる世界が違いすぎる >>115
2002年はPHPではなくPerlじゃね?
Perlも息が長い
というよりRubyやPHPより長生きするかも そもそも繰り返しは、集合演算で表現だね
学生時代から並列処理スレッド処理前提で
言語処理系やアーキテクチャを考えている専門家にとっては
手続き型vs宣言型は最初からあるパラダイム変換問題に過ぎない RDBで無限ループを作られると致命的だからSQLでループ処理は記述できないほうがいいな
SQLインジェクションに使われたら終わる >>120
20年弱って書いたじゃん
2000年代半ばにはもうPHPがレガシー化し始めてた
言語の公開順番はPython、Perl、Ruby、PHPだったはずだけど、前の3個はほぼ同じ時期に出た同世代のスクリプト言語
Perlもかなり前に作者が開発辞めてなかったっけ >>122
キチガイジの妄想の世界だね
SQLをいじってて集合演算を理解できない人が居たとは >>122
SQLインジェクションはwhere句に「or true」となる条件さえ与えてやればええからループとかあんま関係ないかも SQLでループ必要な場合ってツリー構造を再帰的に取得する時とか?
ループが必要になった場合に設計し直した方がいいんじゃない >>125
いやループ句を新設されると無限ループを簡単に作られてまずい、という意味 >>127
テーブル3個ぐらい直積でもやばいかもしれんけどもね
ナウなヤングはNoSQL SQLでやるのにループが必要になる時点で設計ミスってるぞ SQLの宣言型言語表現は、データ・ドメインの主5に参照側に向いた性質
SQLであっても、挿入/削除/その他テーブル追加等の更新/メンテナンス系は、データに変化を与える関係上手続き的性質を持たざるを得ない
またRDBを使うアプリ側は、多分に手続き的性質を持つ
後者二つの領域を、手続き型言語(もしくはそれとマッピング可能な別表現)で記述するには、別言語(上に上がったスクリプト言語やJava、C/C++/C#、レガシーなCOBOL等)への埋め込みSQLやSQL操作ライブラリーを経由するのが一般的
ただしBigSQLの場合、SQLは便宜的な利用インタフェースに過ぎないから、細かな処理をゴリゴリ書かなければならない時は、BigData処理系ネイティブのライブラリを使った方がエキスパートにとっては扱い易いだろうと思う >>129
裏で動く内部データ処理のイメージが無いと
SQLの字面だけで判断して効率の恐ろしく悪いデータ構造やデータ操作をしそう >>134
nested loop × nested loop × Table full scan
のイメージやね カラムのnot指定が欲しい
*やりたくないけどほとんどのカラムみたいって時がある 集合演算の言葉で説明してみ
アプリ側ロジックの話とSQLの話を混同しているような気がする >>92
ひたすらunionすればいけそうだが物凄いコストになりそう SQLが実体化したのがエクセルです
覚えておきましょう >>92
似たようなテーブルをできるだけ一つにまとめて
大きく差異がある部分だけ1つまたは複数の別テーブルに
分ける事ができればいいんだろうね
でもテーブル再設計となるとデータ一貫性を保った操作やアプリ側変更がややこしくなるから、稼働中のデータベースではなかなか難しい >>143
キチガイジさん今日は何時まで妄想を書くの >>138
それ、SQLを吐き出すスクリプト作って
RDBのメタデータから特定テーブルのカラム一覧持ってきて、拡張仕様のNotに当てはまらないカラムだけ並べれば解決だね
Javaだとその辺が標準ライブラリで書けた >>137
直積の場合はmerge join やった。。 SQL豆知識だけど
union ← 重複チェックあり 件数増えると超重い
union all ← 重複チェックなし シンプルに付け足すだけ
おそらく世の中で使われてるunionの9割はunion allで済むと思われる 勝手にループする電卓があったら怖いだろ
SQLがループしないのはそれと同じ理由だぞ >>99
オプティマイザが糞だったりするしな。
ヒント句使って実行計画固定化するなんてこともよくあること。 ループにするのは、良く言えば可読性のため、悪く言えばSQLに習熟できてないから。 大卒なんだけどIT業界とは言え末端の作業者になるとブラック労働にしかならなさそうなのがな
プログラミングは既に出来るんだけど労働集約型産業がとこもブラックなのがトラウマでIT行くのも怖いわ >>123
phpより今はむしろrubyがオワコン感ある
railsをもてはやしてたweb系スタートアップの連中は、サービスが成功してコードベース巨大化した際の限界にぶち当たって別に乗り換えた golangとか、いまだとサーバサイドjacascriptとか
phpはなんだかんだ色んな要素を入れていった結果、ide前提にすれば静的型付け言語チックに、オブジェクト指向っぽく開発できるようになっていった
速度面でも数年に一回は数十%レベルでの速度上昇が入っていてrubyと差がついてってる
昔は色々あったフレームワークも大体laravel一強になって、googleの国内トレンドでもlaravelがrailsを逆転した
なんだかんだでしぶといよphpは 数百万万レコード舐めながら処理するって恐ろしいよな
長いこと運用してると24時間経っても処理が終わらんとかザラにありそう >>157
最新のPHPとか爆速だからね…しばらく触ってないやつは早すぎてびびりそう
Laravelはアジアやら中東、アフリカとかの新興国の地域で強くてアメリカ中心のRailsとは違う独特のポジションを獲得出来てるのがでかいんよね
というかruby/Railsを利用する国がほぼ日本かアメリカってやたら偏ってるんだよな… スレタイみたいな発想の人は関数型言語の集合演算や宣言型の考え方に慣れたほうがいい どんだけそれっぽいこと書いてても結局は40代以降で首切られる業界じゃん そういうのやりたいならmongodbとか使えば
db.kenmomans.find({}, {$job:1}).forEach(ken => {
print(!ken.job ? '無職' : '有職')
});
カーソルでループ出来るぞ
まずやらんけど よっぽどの事がなければDB側に余計な計算処理入れるべきでないと思うわ
ロジックは極力1箇所に固めるべき SQL-92の文法で後方互換を保とうとしてるのがネックだよね 俺はもう他言語組み合わせやるのが普通になってるから何が不便なのか分からないな DBサーバでやるかアプリサーバでやるかでどっちに負荷をかけるか調整したいのかも 結局はどこかで別言語に頼るんだから、シンプルにSQLはデータの読み書きだけって役割分担しといたほうがいい。 行比較は相関サブクエリかウィンドウ関数でやればいいっしょ 大規模システムだと、そもそもSQLで複雑な処理をやるパターンを見たことがない
一昔前はDBパフォーマンスが一番システムのネックになりやすかったから、
インデックスを最大効率で使えるクエリ以外の実行を許さないなんて現場も
結構あった >>166
forEach以降はjavascriptじゃん >>174
このforeachは配列のじゃなくてmongodbのfindメソッドが返すcursorオブジェクトに定義されてるものだから
DBでループしてると言っても差し支えないんじゃない
内部的には最初に101件取得して102件以降は16MBずつ持ってきてるのを表面上ただのループに見せてる
そもそもmongoシェル自体javascriptみたいなもんだし なんか、適当に検索して、そのカラムの値ごとにアレをするだのコレをするだのという
へんなことをしようとするからそういう処理が必要になるのさ
DBの設計が悪いのさ
ループ処理なんてのは、goto文レベルで使う必要が無い物 今もうSQL書かねえわ
active recordにやってもらっちゃってる バッチ処理だとループ使いたい気持ちも分からないでもないけど
db.kenmos.find({}).forEach(k => {
db.kenmos.updateOne({_id: k._id}, {$set: {sex: k.sex === 1 ? '男' : '女'}})
})
なんて事するよりある程度絞って一括で取得してから一括で処理する方が絶対早いし
DB関係の処理は余程の事が無い限り接続の回数減らす方が早いイメージ というかカーソルあるならSQLでもNoSQLでも関係無くループは出来るか
調べ物する時ぐらいしか使う事ないけど
redisでガバガバワイルドカードのkeysぶち込んだら怖いし おすすめのNOSQL書いて毛wwwwwwwwwwwwwwwww >>20
表形式で結果を取らなきゃSQLの意味ないわな。
ループで渡す変数を範囲で渡せよと。 sqlは根本的にループ処理するようにはできてない
やるならplsqlとかsqlを拡張する手段を取るしかない Entity Frameworkってさ
この関数はSQLに変換出来ませんこの構文も出来ませんばっかりで不便すぎない? with句ねえな
ほとんど素人しかいないんやなwwww >>148
俺もニワカ知識でそう思ってた次期あったけど実際にチューニングしてみたら何故かUNIONの方が最適な実行プランになって処理速度が早いとか普通にあんだよな SQLは宣言型プログラミング言語で、何をやるかを書けば良くてどうやってやるかを内部に閉じ込めるんよ
ループはどうやってやるかを書くものなのでSQLでは使えないよ
ループして何をするのかを分析してSQLで書けないか調べるのが本筋 >>8
クソみたいなSQLのチューニングやり続けてくれる人は現場的には需要ある
クソみたいなSQLがあふれてることを偉い人が認めたがらないからPJにそういう枠がそもそもないけど 不便だと思うなら、DBA権限もらえるようになればいい
DBA権限あれば、不便なことは何もない
失敗したら死亡するだけだ ■ このスレッドは過去ログ倉庫に格納されています