ふたばも滅ぶのでは？

SQLにそんな恨まれるようなとこあったか…？

DB設計者恨んでSQL憎まずですよ

SQL滅びないで…

集合論と述語理論がどうのこうの

じゃあORM使うか

最近はChatGPTにDDL渡してこういうデータ欲しいって雑な指示するだけでパーフェクトなSQL書いてくれるから超ラク

時代はNoSQLよ！

>時代はNoSQLよ！
用途次第だろ！

何も考えずに流行りでNoSQLに飛びついた連中は運用で苦労する

>ほろびろOracleSQL！

ﾎﾟｽｸﾞﾚだけあればそれでいい

SQL滅びたら結構なシステム死なないか…？

JDBC経由で毎回使うからどんなSQLが流されているのか確認出来て楽
ORM使うと…

カラムにJSON格納して苦労してる

SQL滅びたら俺生きていけない…

無駄な！！！！！！！！１
INNERJOINを！！！！！！！！！！！！！！
するな！！！！！！！！！！！！！！！！！！！！！！！！

>無駄な！！！！！！！！１
>INNERJOINを！！！！！！！！！！！！！！
>するな！！！！！！！！！！！！！！！！！！！！！！！！
や！！！だ！！！

カラムにJSON使うなLONGTEXT使え
フロントエンドが悶絶しているの見て笑ってしまった

SQLは滅びないけど
SQLが書ける人の仕事が滅びる

FROMから書きたい

1=1

分かりましたLEFT OUTER JOINしますね
これ言って即現場降ろされた奴ならいた

>や！！！だ！！！
お前のちんこちょん切るぞクソ野郎！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！１１

まあオプティマイザが上手くやってくれるだろう…

今ちょうどSQLの勉強してて結合ってクソなのでは？って思ってたんだけど間違ってなかったのか

>SQLは滅びないけど
>SQLが書ける人の仕事が滅びる
SQLしか書けない人はマジで希少だから問題ないな！

DISTINCT楽しい！

>今ちょうどSQLの勉強してて結合ってクソなのでは？って思ってたんだけど間違ってなかったのか
結合は超便利
使う人がクソだと超クソクソクソクソ性能考えろ

SQLはアセンブリ言語のようなものだと聞いた
直に触るものではないという意味で

VIEW使って全データのVIEW作るのとWITH句で逐一必要なデータだけ抽出して結合するのどっちがいいんだろう？
現場毎で凄い分かれるから何が正しいのかよく分からん

>SQLはアセンブリ言語のようなものだと聞いた
>直に触るものではないという意味で
それはビビりすぎ

逆に直に書きすぎてORMの機能を信用していない「」もそこそこいるとか

>VIEW使って全データのVIEW作るのとWITH句で逐一必要なデータだけ抽出して結合するのどっちがいいんだろう？
>現場毎で凄い分かれるから何が正しいのかよく分からん
使う頻度が高いならViewにした方が早いと思う

SQLぜんぜんわからん
どうやって勉強すればいいの

SQLの何が嫌っていうんだ！

>SQLぜんぜんわからん
>どうやって勉強すればいいの
書いて覚える！
あとこれとかやってみるといいよ
https://topsic-contest.jp/home

分からない…俺は雰囲気でSQLを使っている…

Insertを件数分ループで回す
これに尽き申す

結合は悪くない
設計が終わってると地獄になるだけで

これ直接触らなくていいパッケージたくさん出てきてるけどそういうのでDB作ると大体パフォーマンスがやばくなる気がする

帳票やリストで複数テーブルをJOINしないといけない時は基本VIEW作ってそこから取り出すが一般解だと思っている
VIEWを知らないPMがいる？うんなんでそんなやつがPMしているんですか？

>まあオプティマイザが上手くやってくれるだろう…
explainくらい確認してくれ
いやしろ

SQLの勉強する前に流すデータを生成するのが手間…
1000超えるともうその時点でやる気無くす…

結合条件をVIEWの値として持ってそれを参照しながら値を返すVIEWはちょっとこれ無茶じゃないかなってなった

>Insertを件数分ループで回す
>これに尽き申す
入るデータが間違えなければええ！

>Insertを件数分ループで回す
>これに尽き申す
Prepared Statement使うならそうなりがち

すみません先輩の作ったACCESSが膨大なサイズのエラーファイル吐いて読み込めなくなってるんですけど！

>SQLぜんぜんわからん
>どうやって勉強すればいいの
データ移行の案件に入って移行用のSQL書きまくってたら体が覚えた

NoSQLってお勉強的に触るならどれがいいの

>すみません先輩の作ったACCESSが膨大なサイズのエラーファイル吐いて読み込めなくなってるんですけど！
ご愁傷さまです

>>すみません先輩の作ったACCESSが膨大なサイズのエラーファイル吐いて読み込めなくなってるんですけど！
>ご愁傷さまです
たすけて…ウェブクエリにも読み込ませないといけないの…

>>>すみません先輩の作ったACCESSが膨大なサイズのエラーファイル吐いて読み込めなくなってるんですけど！
>>ご愁傷さまです
>たすけて…ウェブクエリにも読み込ませないといけないの…
先輩に助けて！って泣きつこうぜ

>帳票やリストで複数テーブルをJOINしないといけない時は基本VIEW作ってそこから取り出すが一般解だと思っている
>VIEWを知らないPMがいる？うんなんでそんなやつがPMしているんですか？
一次受だからですね…

>結合条件をVIEWの値として持ってそれを参照しながら値を返すVIEWはちょっとこれ無茶じゃないかなってなった
テーブル全結合したもの持っておいて逐一集合条件を参照するVIEWとして使う事はある

時代はNOSQLだぜ！！！

何でもかんでもJSOMでやるなよ！過去に設計したやつ！ってなってる

>>>>すみません先輩の作ったACCESSが膨大なサイズのエラーファイル吐いて読み込めなくなってるんですけど！
>>>ご愁傷さまです
>>たすけて…ウェブクエリにも読み込ませないといけないの…
>先輩に助けて！って泣きつこうぜ
ずっと会議中になってて反応がないんだ…
とにかく今もなお増え続けているこの巨大な.databaseファイルをなんとかしないとヤバい！！

そういえばどうやってSQLを覚えたか忘れたな…研修ではサッパリだったから実務で覚えたと思うんだが…

無駄なINNER JOINってどういう状況で発生するの…？

JSONはフロントエンドが.toString()してそのまま使える奴だけ使うって認識でいる

発注側だけど今まで見た中で一番やばいPMはWBS知らないやつだった

ChatGPTがお出しする回答ってそのSQLが妥当かどうか判断できる内容が含まれてるの？

>発注側だけど今まで見た中で一番やばいPMはWBS知らないやつだった
何しに来たのその人

何をマネージメントするのその人

>発注側だけど今まで見た中で一番やばいPMはWBS知らないやつだった
テレ東でしょ？知ってるんだからね！

テレ東のやつでしょ？
毎晩ちゃんと見て知見を深めてますよバカにしないでよね！

SQLやスクリプト言語とかきちんと構文がある系の生成はメチャクチャ強いよChatGPT
依頼が正しければほぼ間違えない

>今まで見た中で一番やばいPM
そこの人寝てるんだよね?死んでないよね?

カビ臭い設計でとにかく結合前提みたいなやつは総じて滅んで欲しい

>無駄なINNER JOINってどういう状況で発生するの…？
カラム使いたいわけじゃないけどそこのカラム見たい〜みたいな？

リビジョン最新のレコード一括取得したいからMAX使ったサブクエリを内部結合するね…
うおすっげえ重い…

>無駄なINNER JOINってどういう状況で発生するの…？
キー項目でINNER JOINするだけで特にJOINしたテーブルへの参照はない
WHEREに副問い合わせ書いてそっちでやれ！

>カラム使いたいわけじゃないけどそこのカラム見たい〜みたいな？
良し悪しはあるかもしれんけどそれは無駄ではなくないか…？

SQLに罪はないよ
SQLは人類が生み出したものの中でもかなりいい線いってるものだと思う
使いこなせない人間が悪いゴミカスクズクソテーブル設計できないヤツが悪いアホ

>>カラム使いたいわけじゃないけどそこのカラム見たい〜みたいな？
>良し悪しはあるかもしれんけどそれは無駄ではなくないか…？
カラム使わないならEXISTSとかでよくない

>何しに来たのその人
わからん…やっぱり燃えたしパフォーマンス問題もおきた

テーブルの設計の良し悪しとかもよく分からないからマジで雰囲気で続けててこれはよくない…

ChatGPTは質問が雑だと間違った回答吐き出したりするけど簡単に叩き台作れるからめっちゃ便利

AIくんよろしくお願いします

最近のPMはプレイヤーの単価上げるためについでにPMもさせているみたいなやつ多いからWBS？進捗管理？
知らねえ俺が書いて終わらせるから問題なしって事多い

>SQLやスクリプト言語とかきちんと構文がある系の生成はメチャクチャ強いよChatGPT
すごいなAI
>依頼が正しければほぼ間違えない
急に無理難題が来たな……

ここに論理削除フラグ置いておきますね

ChatGPTは使う側にも知識が必要
「」も自分が詳しいゲームとかで確認してみるといい

>カラム使わないならEXISTSとかでよくない
使いたいと見たいがそれぞれ何を指してるのかわからなくなっちゃった
ごめん

>カラム使いたいわけじゃないけどそこのカラム見たい〜みたいな？
そういうテーブルの設計した時点で設計がゴミなのでは…

俺が構文調べて最初から作るよりは絶対早くて確実なのでまずAIくんに聞きます

機能に応じて設計せずにテンプレ使い回すのはあるあるだから…

新規システムでもなければテーブル設計はグチャグチャになっていくのでもう仕方がない

>俺が構文調べて最初から作るよりは絶対早くて確実なのでまずAIくんに聞きます
は？こんな構文ないだろ？これだからAIは…
で調べると便利なものがあって勉強になります

>は？こんな構文ないだろ？これだからAIは…
>で調べると便利なものがあって勉強になります
コーディング規約で禁止されてるううううううう！？！？！？

SQLは悪くないよ
DB設計が人類には難しすぎるんだ

ChatGPTくんもクソみたいな要件定義投げられて困る側だったか…

AIくん俺正規表現分からないからちょっと解説して

アレな質問なんだけど
ユーザーテーブルをINSERTやUPDATEする時
企業IDと名前が一致する同名は更新出来ない様にしたいんだ
前に更新前に一致したら業務エラーで弾くって言うのをやっていたんだ
それだとコンマ数秒であり得る可能性ありますよねってアレな事言われたんだがどうしたらいいんだ？

ネットにある更新時にサブクエリでやる方法はトランザクションエラー発生するからダメだった

indexに沿ってコーディングしろよ！！！！性能でねえだろ！

絞り込み条件で他テーブルの内容使いたいだけでINNER JOINするのはちょっと…

>indexに沿ってコーディングしろよ！！！！性能でねえだろ！
なんとインデックスが設定されていないのである

>>indexに沿ってコーディングしろよ！！！！性能でねえだろ！
>なんとインデックスが設定されていないのである
データベース誰が設計したんだよ…

SQLは滅ぼさなくていいけどマイクロソフトさんちのAccessは滅ぼして欲しい

>なんと主キーが設定されていないのである

>ユーザーテーブルをINSERTやUPDATEする時
>企業IDと名前が一致する同名は更新出来ない様にしたいんだ
>前に更新前に一致したら業務エラーで弾くって言うのをやっていたんだ
>それだとコンマ数秒であり得る可能性ありますよねってアレな事言われたんだがどうしたらいいんだ？
日本語でOKって感じだけど常にユニークなカラムを用意したいってこと？
ユニーク制約つければいいだけじゃないんですかね？

サブクエリ使うのだめよって言われたからINNER JOINでいいよね

ヘルプ入ったらインデックス貼ってないのよく見る
人類は思ったよりやばい

>サブクエリ使うのだめよって言われたからINNER JOINでいいよね
どんなクソ案件だよ

>>>indexに沿ってコーディングしろよ！！！！性能でねえだろ！
>>なんとインデックスが設定されていないのである
>データベース誰が設計したんだよ…
インデックスは後で決めようねのまま放置とかあったよ

>AIくん俺正規表現分からないからちょっと解説して
╰⋃╯ (i)

なんでACID特性持ったDB使ってるのにコンマ数秒でありえますよねみたいな話が出るんだよ…
ファイルにでも書いてんのか？

>>依頼が正しければほぼ間違えない
>急に無理難題が来たな……
機械は何も間違えない
扱う人間が間違ったら間違った指示を正しく実行する
って昔聞いたの思い出した

主キー無いはありえるの…？

>>>>indexに沿ってコーディングしろよ！！！！性能でねえだろ！
>>>なんとインデックスが設定されていないのである
>>データベース誰が設計したんだよ…
>インデックスは後で決めようねのまま放置とかあったよ
基本設計ないがしろにしてるやつ！絶対バグあるわ…

でもインデックス設計するのは難しいし…

>主キー無いはありえるの…？
揮発性高い一時テーブルならまあ…ただ普通はありえない

重くなったら貼ればいいだろは誰も貼らない

>日本語でOKって感じだけど常にユニークなカラムを用意したいってこと？
>ユニーク制約つければいいだけじゃないんですかね？
複合主キー制約調べたらこれでいけそうな気がした

>ヘルプ入ったらインデックス貼ってないのよく見る
>人類は思ったよりやばい
性能が出ないすぎる！！！このままじゃ大炎上大損害！！！至急ヘルプ！！！って言うから出張して駆けつけたら何もインデックス張って無くてインデックス張ったら全部解決したことある
ねぇ超緊急大至急っていうから1週間分の宿抑えて出張してきたんだけど俺あと4日と7時間何すればいいの…

>>サブクエリ使うのだめよって言われたからINNER JOINでいいよね
>どんなクソ案件だよ
サブクエリ使うと単価の安い人間が読めないでしょ！
簡単なINNER JOINにしなさいってところならそこそこあるよ

でもさぁどっちかというと気を利かせてインデックス貼ってくれない方に問題があるんじゃない？

世界にはもっと限界寸前の現場があるからインデックスが無い程度はセーフだ

多分なんとかなると思うから実行計画を固定しようぜ

>サブクエリ使うと単価の安い人間が読めないでしょ！
>簡単なINNER JOINにしなさいってところならそこそこあるよ
やば...

>でもさぁどっちかというと気を利かせてインデックス貼ってくれない方に問題があるんじゃない？
なるほど一理ありますね
その基になる設計は作りましたか？

>>indexに沿ってコーディングしろよ！！！！性能でねえだろ！
>なんとインデックスが設定されていないのである
横からだがRDSのインスタンスタイプ下げられないかって相談されてinsights見たらindexないテーブルがCPUとIO食ってるの見てダメだったことがある
基本のキから始めたら余裕でワンランク落とせてめでたしめでたしだったけどそのプロダクトのエンジニア連中何考えてるんだ…ってなるなった

>サブクエリ使うと単価の安い人間が読めないでしょ！
>簡単なINNER JOINにしなさいってところならそこそこあるよ
SQLに限らずVBAでも普通の開発でもよくあるやつ

そのうちAIが気を利かせてインデックス張ってくれたりするようになるんだろうか

>主キー無いはありえるの…？
30年前のベンダーに言ってほしい

>基本のキから始めたら余裕でワンランク落とせてめでたしめでたしだったけどそのプロダクトのエンジニア連中何考えてるんだ…ってなるなった
そうやってちょっと問題解決してよって投入された人は強権揮える場合が多くていいけど
既存メンバーは自分のお仕事に手いっぱいで内部の調整する時間がなかったり
言いだして割を食うのが嫌で気付いても放置とかよくある

適当に会社用の報告資料作って
あとは観光でもして帰るとか…

※インデックスはいくら付けてもよい

まあインデックス付けてもオプティマイザ神託が心変わりすれば激遅なんだがなブヘヘ

開発初期にリーダーが抜けたゴタゴタと誰かがやるだろ…でUAT始まってからインデックスひとつも貼ってない問題が噴出したのがウチだ

必要になったインデックスを後から貼るのは容易だけど貼られてるインデックスが不要かどうかの判断は難しいし…

酷いのになるとSQLってなんですか？と日本語分からないで〜す！はクソ現場だとあるある

サブクエリの入れ子構造にするのは許すから
せめてインデントやコメントつけて

現場ガチャに外れた奴から退職していく…

from h
left join a as aa
on h.key = aa.key and aa.param = hoge
left join a as ab
on h.key = ab.key and ab param = foo

>そのうちAIが気を利かせてインデックス張ってくれたりするようになるんだろうか
勝手にかはともかくSQLServerはインデックス足りてません😡って教えてくれる
俺はその通りにする
すると本当に早くなるんだ
不思議だね

NOTNULLの代わりにPKにするやつ死ね

DB畑の人は上のマネージャーとかコンサルっぽい方向に行きやすそうでうらやましい

NULLに意味を持たせるの止めて欲しい

>>そのうちAIが気を利かせてインデックス張ってくれたりするようになるんだろうか
>勝手にかはともかくSQLServerはインデックス足りてません😡って教えてくれる
>俺はその通りにする
>すると本当に早くなるんだ
>不思議だね
ありがたい…

最近はサブクエリじゃなくてWITH句頼りになっているよ
サブクエリだらけのSQLなんてもう読めるかすら怪しい

PL/SQLにgoto文がある事を先日知った
まぁ使うなって御定されたが

WITHはこっちはこっちでなんか読みづらい…

>まあインデックス付けてもオプティマイザ神託が心変わりすれば激遅なんだなブヘヘ
完璧な統計情報をよこさない方が悪いとオプディマイザも言っています

SQLは触りしか知らんけど文法が独特すぎて好きじゃない
それ専門でやるならいいけどアプリケーションとのやり取りするときは脳内リソース分割されて辛い

>PL/SQLにgoto文がある事を先日知った
>まぁ使うなって御定されたが
昔多用したぞ
ツール用としてロジック組めって言われて仕方無しに
作ってて吐き気をもよおしたわ

DBの初学者の記事にDB界のえらい人が最近キレててこわ〜ってなった

単体ならともかくあちこちで使うならdecodeでなくviewでデコードしといてよ…

マテリアライズド・ビュー？
これ無かったことにならないですかね…

うまく結合して情報抜き出せるとなんか嬉しくない？

>最近はサブクエリじゃなくてWITH句頼りになっているよ
>サブクエリだらけのSQLなんてもう読めるかすら怪しい
昔のPJで当時のDBMSがサブクエリ複雑になるとWith句と比べてめちゃくちゃ性能落ちたからサブクエリ禁止して全部With句にしたことあるわ
メモリ潤沢に使えるならWith句でいいよね読みにくいとかは知らん気合で解読しろ

めんどくせえから全部インデックスつけるかァ！

>SQLは触りしか知らんけど文法が独特すぎて好きじゃない
>それ専門でやるならいいけどアプリケーションとのやり取りするときは脳内リソース分割されて辛い
アプリでなんとか出来るんならシンプルでいいんだぞ？

なにやっても早くなんねぇ！お手上げ！と思ってたら数値を文字列で検索かけてたみたいなのがあった

SQLはCPUとメモリとのせめぎ合いだからな…

DAOいじるのもうやだ…

DB設計まじでわからん…最初どこまで想定して作ればいいのかそれとも最低限から始めて後で判断した方がいいのか
とりあえず動いてるけど何もわからん…

可読性をみんな軽視しすぎ!と思ってる
育った地方の方言出すぎよ

SQL憎しで全部ORMで済まそうとするのだけはやめてください

ロールバックとトランザクションとロックが絡んで来ると結構頭痛くなる
コードってよりPMや上に説明する時

>可読性をみんな軽視しすぎ!と思ってる
>育った地方の方言出すぎよ
作るお前はそれでいいかもしれないけどメンテするのはお前ではないからな

>作るお前はそれでいいかもしれないけどメンテするのはお前ではないからな
つまり可読性は大事って事だね

>DB設計まじでわからん…最初どこまで想定して作ればいいのかそれとも最低限から始めて後で判断した方がいいのか
>とりあえず動いてるけど何もわからん…
データ設計をきちんとしよう
業務上どういうデータが必要で数がどれくらいあるのかそのデータをどういう検索をする必要があるのかを整理するんだ
業務側も分かってない�d

>マテリアライズド・ビュー？
>これ無かったことにならないですかね…
当時からこんなもの人類に扱えるわけないだろと思ってたよ

メンテするのは高確率で単価の安いアレな人
設計書読めない　SQL読めない　助けてください！電話してくるなよ！

どうしてSQLすらロクに書けない人にDB設計任せてしまったんですか…どうして

正規化しすぎるとテーブルが多すぎると苦情が着て
いい感じに正規化するとどうしてこんな中途半端な分け方したんだと苦情を言われる
DB設計なんてそんなものだよ

>どうしてSQLすらロクに書けない人にDB設計任せてしまったんですか…どうして
失礼な
実装できるかどうかわからんレベルの新人の記念作品みたいな基礎設計で顧客と合意してしまった尻拭いよりマシ

>正規化しすぎるとテーブルが多すぎると苦情が着て
>いい感じに正規化するとどうしてこんな中途半端な分け方したんだと苦情を言われる
>DB設計なんてそんなものだよ
DB設計は常にいい感じを求められている気がして難しいなって思う

新人の仕事自体は百歩譲って許そう
どうして設計書レビュー通してしまったんですか

皆疲れてるんだよ

SQL滅びたらどうしたらいいの？
ファイル管理？？

クエリ生成がはちゃめちゃかつ膨大でバーカ滅びろ実装者！になったことはある

初心者な質問だけどVIEWで結合した時に最後の枝が2本に分岐
（例えば仕事IDが主キーでactIDがテーブルまたがって連番
テキストと写真は別のテーブルに持っている）
なんて時にどうやって結合する？

>新人の仕事自体は百歩譲って許そう
>どうして設計書レビュー通してしまったんですか
誰もデータ設計をしていないからですかね…
必要に応じてありとあらゆるテーブル同士を結合できるための結合マスター表なるものが用意されてる謎のプロジェクトは本当に酷かった
これがあるからどんなテーブルも結合が自由自在なんですよじゃねーよぶっ殺すぞってなった

>つまり可読性は大事って事だね
俺は読まないから…
終わったら抜けるし

SQLを辛うじてかけるぐらいの若手が作ったテーブルを見たけど凄かったな…
・主キーもプライマリーキーなし外部キーなんてあるわけない
・履歴テーブルでもないのに名称を全トランザクションテーブルに持ってる
・形が全部varchar(255)

--commit

入れ替わり激しい現場のコードってSQLに限らず保守性クソなの多くない？

>SQL滅びたらどうしたらいいの？
>ファイル管理？？
ここにNoSQLがあるじゃろ

>入れ替わり激しい現場のコードってSQLに限らず保守性クソなの多くない？
短期で入って終わったらサヨナラってやったらそうなるよね

>・形が全部varchar(255)
むほほ

>SQLを辛うじてかけるぐらいの若手が作ったテーブルを見たけど凄かったな…
そういうのでお金貰えるならIT業界って実はぬるいのでは無いかと勘違いしてしまう…

いつのまにかreadログでかつかつになってた

>そういうのでお金貰えるならIT業界って実はぬるいのでは無いかと勘違いしてしまう…
そう言う意味でなら間違いなくぬるいよこの業界
特にフリーランスとかよくその技術でその単価貰ってるな！？みたいなのしょっちゅうある

SQLは分かる人高い単価で呼んで触らせるのが正解だっていうのをPJがアンチパターンするからね
その新人3人よりこっちの熟練1人雇ったほうがお安いんですよ

>・履歴テーブルでもないのに名称を全トランザクションテーブルに持ってる
性能を限界まで高めるのが必要な場合はテーブル結合禁止の場合もあるから…

>SQLは分かる人高い単価で呼んで触らせるのが正解だっていうのをPJがアンチパターンするからね
>その新人3人よりこっちの熟練1人雇ったほうがお安いんですよ
これまで作業者レベルでやってたDB設計を専任置いてやらせた方が品質高かったわ

なんでもvarcharマンはどうして生まれるんだろう…

怒られること承知で言うけどエンジニアは技術無くてもなんとなく前からの秘伝のタレ流用と間に合わせの仕事でもおちんぎん他の業界よりはるかに多く貰えるからチョロいよ…良くないと思うけど…

>そういうのでお金貰えるならIT業界って実はぬるいのでは無いかと勘違いしてしまう…
ぬるいからレッツジョインアスなんやな
3日後恐るべき事態に──

データベースは正直SQLで悩むことは一切ないけれど圧倒的にストレージ管理だのレプリケーションだのクラスターだので悩むし困る場面が多い

ER図やCRUD図をちゃんと作ってる現場は案外少ない

他人の技量がはっきりと感じられる業界だからよほど恥知らずじゃないと辛くない？って思うんだけどね
俺はいつも俺よりできる奴を殺す気でやってるぞ

>そういうのでお金貰えるならIT業界って実はぬるいのでは無いかと勘違いしてしまう…
機関システムの長老のフリーランスおじさんとかね…

>・履歴テーブルでもないのに名称を全トランザクションテーブルに持ってる
まさかして商品IDとかマスターの一覧みたい時UNIONしているって事？

>他人の技量がはっきりと感じられる業界だからよほど恥知らずじゃないと辛くない？って思うんだけどね
>俺はいつも俺よりできる奴を殺す気でやってるぞ
俺は誰よりも出来ないから助けてくれでやってるぞ
恥知らずでよかった

>なんでもvarcharマンはどうして生まれるんだろう…
項目長は諦める
せめて文字列と数値は使い分けてくれんか？ソート順が…

IT業界は人手不足なのでぜひ入ってきてくださいね

>>・履歴テーブルでもないのに名称を全トランザクションテーブルに持ってる
>まさかして商品IDとかマスターの一覧みたい時UNIONしているって事？
いや商品名を商品IDを持ってる全トランザクションテーブルに持ってた
「マスタメンテで商品名変わったときは？」と聞くと「全トランザクションテーブルをアップデートします！」って元気よく返事してたよ…

もう身に付いてるからチョロいと思ってるけど君たちはすごい人たちなんだ
ここで言われてる連中も他の業種と比べたらマシ
いやこれは言い過ぎたかもしれん

開発で入ったのに保守要員にされてコード書くよりSQL書く方が長くなってちょっとわかるようになった

>>他人の技量がはっきりと感じられる業界だからよほど恥知らずじゃないと辛くない？って思うんだけどね
>>俺はいつも俺よりできる奴を殺す気でやってるぞ
>俺は誰よりも出来ないから助けてくれでやってるぞ
>恥知らずでよかった
恥知らずのほうが伸びるから安心しな

withがわからん
joinにselectかいたらあかんの？

自分でやるならまあ…引き継ぐ前提ならうん…

他人に任せきりで終わってなければ伸びるかもしれんが…

>「マスタメンテで商品名変わったときは？」と聞くと「全トランザクションテーブルをアップデートします！」って元気よく返事してたよ…
リレーショナルってなんだろうな…

>IT業界は人手不足なのでぜひ入ってきてくださいね
ハラスメントが無くなれば最高の現場なんだけどな…

>withがわからん
>joinにselectかいたらあかんの？
プログラムにおける関数化みたいなもんだ
同じサブクエリを複数回つかいたいならwithに書いたほうがすっきりする
俺は複数回使わなくても可読性のためにwithに書いたりするけど

>joinにselectかいたらあかんの？
パフォーマンスが違うのと可読性が少し上がる（読みやすいとは言ってない）

協力会社の人の方が俺より詳しいし早いし…
俺はくっちゃべってなんかまとめてダメージ発生したら身代わりになる役だ

>withがわからん
>joinにselectかいたらあかんの？
実現される機能的には同じなんだけどなんか知らんがWITHのほうが性能良くて副問合せだと性能でねぇなってときがあるんだ
DB製品の動作の中身まで詳しいDBマニアなら理由を説明できるかもしれないが俺にはわからん

触ったことないSQL文をいきなり作れ！って言われて見よう見まねで作り出してから今にかけて雰囲気だけでSQL文書いてる...

>パフォーマンスが違うのと可読性が少し上がる（読みやすいとは言ってない）
知らない構文！なにやってるかわからないので直してください！

>触ったことないSQL文をいきなり作れ！って言われて見よう見まねで作り出してから今にかけて雰囲気だけでSQL文書いてる...
問題無い程度に動いていればええ！

>リレーショナルってなんだろうな…
（IT土方）リレーって意味だよ

実行計画採るときもwithにしてたほうが見やすかったりする

ここで言われてるような地雷は踏んでないけどなんとなくその方がいいと思って踏んでないだけだ
俺は雰囲気で書いている

SQLごと滅ぼそうとするのは斬新だな
かなり多くのものが衰退しそう

>協力会社の人の方が俺より詳しいし早いし…
>俺はくっちゃべってなんかまとめてダメージ発生したら身代わりになる役だ
(この社員の人全然動かないし身代わりにもならないし指示も出さない...)みたいな人がいるのですがどうすればいいですか？

>(この社員の人全然動かないし身代わりにもならないし指示も出さない...)みたいな人がいるのですがどうすればいいですか？
ほろぼせ

SQLのバージョンが古すぎてWITH句自体が対応していない時がわりとある

お前はWhere句でデータを抽出して！
俺はINNER JOINでデータを抽出する！
そこに何の違いもありゃしねえだろうか！！

>SQLのバージョンが古すぎてWITH句自体が対応していない時がわりとある
with対応してないRDBってそれもうサポート切れてないかな…