ノリさん何でしょうSQLってやった方がいいですよねやった方がいいのは僕も知ってるんですよ知ってたか知ってましたなんでちょっとおかしくなっちゃいましたやった方がいいですよねSQLやった方がいいですよですよねSQLはね汎用的なんですよねはいはい

っていうのも大体データベースいじるときとかってほとんどのデータベースってリレーショナルデータベースじゃないですか製品によってSQLとかオラクルとかAB2とかボスグレとかいろんなデータベースマネジメントシステムって言われてるやつがあると思うんですねでもどれ使っても

SQLって結局似たようなことをやるんですよちょっと違いとかはあったりするけどなるほどデータベース使ってないサイトなんてほとんどないじゃないですかはいないですねっていうことはSQLが使えるとどの現場でも役に立つ力がつくというわけですね汎用的なるほどですねなのでSQLは大事

はいですじゃあ今回はこれぐらいで意味ない回じゃないか意味ない回でしたはいでそうですねちょっと僕がなんとなくやっぱり必要だろうなっていうのは実際その具体的にはどこまで必要なんだろうなっていうところをお聞きしたくてですねなるほどで2つあって1つは自学自習の時とかにはいはい

基本的にどのぐらいのレベルできればいいのか2つ目が実際に現場参画してみて実際どんなレベルでしたよとかこんぐらいの長さでとかっていうのをざっくり聞ければいいなと思ってOKですそもそもじゃあ今のじゅんぺいのSQL力を問うていいですか今のSQL力

うーんなんていうかまあでも僕データベースとかで言うと本当2つしか使ってないポスグレとマイスキュエルまあまあそこはどっちも変わらないよねあんま使い心地そうですねそこぐらいであとマリアDBもまあちょっとマイスキュエルと一緒ですからねそれぐらいですで実際にコードとしては

普通の結合はもちろんできてあとはサブクエリとかある程度はできて基本的なところは比較的できると思うんですよなるほどなるほどテーブル数とかも開発自分でやった開発の時に11個のテーブルとかで4テーブル5テーブルとか結合したこともあってそのぐらいの感じですなるほど

パーフェクトありがとうございますちなみに外部結合と内部結合の違いを述べようとカブリーシャンを排除するカブリーシャンカブリーシャンを排除するカブリーシャンどっちがどっち外部だとテーブル数テーブル数じゃないカラム数一致してなかったりしたら6行と7行とか

その余った一行なんか結合されず消えちゃうみたいな感じの話そうそうそうそうどっちがどっちですかそれが排除されちゃうのが内部されないのが外部どうでしょういや変顔伝わんないです正解よかったあぶねあぶねはいはいですなるほどねギリギリの感じを今感じたけど危なかったまあでもそんなのは調べれば出てくるんではい

存在してる ok ですねはいじゃあちょっと現場で求められる sql のスキルはいということでですねはい sql って命令あんま多くないんですよはいはい同じような感じってことですそうねまあ基本はクラット処理つってはい4つのそうそうそうそうクリエイトリードアップデートはいデリートはいのまあ4つの処理が

基本になってますよと大体この操作できればよくてそれをちょっとサポート豊かにしてくれる仲間たちがいてそれを扱っていくのが主にデータベースの操作になってくるかなと思ってますSQLに関して言うと例えばフレームワーク開発で多分フレームワーク使うこと多いと思うんですけどフレームワークってORMっていうもの組み込まれてるじゃないですかはいはい

ORMって何でしょう?オブジェクトリレーショナルマッピングみたいな。いいね。あってます。惜しい。惜しいけどあってるよ。惜しいけどあってる。オブジェクトリレーショナルマッパーですね。どんなやつですか?えっと…

データベースのテーブルカラムとかとJavaで言えばエンティティとかをマッピングするためのツールみたいなシステムみたいな要はデータベースってさ表形式でデータ入ってるじゃないですかでも

例えばJavaとかPHPとかそういうのでデータ取ってきた時って表じゃなくてオブジェクトになってるじゃないですかなので変換が必要ですよとなのでその変換のことを要はこの表のこの部分をオブジェクトでここだよねみたいな感じでマッピングしていくんでオブジェクトとリレーショナルのマッピングしてますよってことでオブジェクトリレーショナルマッパーと呼ばれておりますよとそういう風なオブジェクトを作って

そういう風なツールがあることによってSQL知らなくてもデータベース操作できちゃうんですよねああ確かに要はメソッド呼び出すだけでセレクトできたりとかアップデートできたりとか用意しておけばってことですねそうそうそうORMがっつり使ってる現場だと実際SQLもしかしたら知識としてあった方がいいと思うけど使う機会はあんまりないかも

ただ現場とかだとORMってちょっとスピード落ちるので変換やってる分だから結構早さにこだわってるとこだとSQLそのまま書いてるみたいなとこあるんですよこのメソッドの時はこのSQL発行しますみたいな感じでソースコードにSQL書いちゃってそれ流すだけにするみたいなこともあって僕の現場はそれでしたねいた時は

で、SQL先ほどの4大命令とその豊かにしてくれる仲間たちがいれば大体OKって言ったんですけどSQL命令少ないのであんまりポッピなことを知らなくても大丈夫です現場のコードもマジで大体セレクト分まあ、はい、ですよねきっとで、そこに対してめちゃくちゃいっぱい

カラム指定してめちゃくちゃいっぱいテーブルジョインしてすごい複雑なウェアアークがあってオーダーバイもすごい複雑なみたいな感じで基礎的なフレーズを使いつつもそれがとんでもないボリュームになってるっていう認識が多分いいかな現場によるだろうけどね僕の言ったとこはそんな感じでしたねそれなら想像できますよくウェブサイトとかだと

不動産のサイトとかだと何件物件ありますよとか求人サイトだったら何件求人ありますよみたいなそういう集計する機能とかあったりするんであとはその集計する部分の関数使うこともあるかなっていうトップですかね基本処理と集計関数ここができると大体の業務は何とかがあるもっと発展的なところに行くと

きっと最初の方は求められないと思うんですけどSQLのチューニングみたいなのをやることもあるかなあんまないかなパフォーマンスがどうもそうなんですパフォーマンスチューニングもSQLをもっと効率いいSQLに変えるケースもあれば普通に設定いじる場合もあるんで設定をいじるデータベースの設定をいじりますそういうことですか

カラフを追加したりとかというよりもデータベースの設定というとちょっとあれなんですけどインデックスって聞いたことあります?インデックス貼ったりしてデータベースを操作っていうのは検索する順番とか変えてより早く見つけるようにするやつですねその辺は正直最初は求められないと思いますねなので基本的な操作をやれば

幸せになれるわかりましたあるんですよねパフォーマンス上げるときにExplainExplainExplainはいExplainは使いますねインデックス貼るときの参考にしますねなんかExplainって説明出るんですねこの実行計画そうそうそうそうこのSQL流したときこういう風に探してるんだなってのが

諸見え諸見えのやつ諸見えになるやつそこら辺使ってパフォーマンスチューニングチューニングするって言うんですかねそうですねチューニングを上げる?チューニングをする?例えばチューニングするっていうかな例えばそのデータベースに1億件入ってたとするじゃないですかでもその1億件の中から1件のデータ探すの大変じゃないですかなのでそのインデックスを使うことによって独自の並べ方するんですよ

そうすると本の作品みたいなもんかな本にキーワードあるけどそれを前から1ページめくってめくって探すの大変じゃないですか大変ですよ1個見つけたとしても残りのページにもある可能性あるから止まれないじゃん止まれない300ページの本だったら300ページめくって全部文字見なきゃいけないと思うんですけど作品が後ろにあるからあれ見たら何ページにどの単語あるって分かるじゃん確かにあれが要はインデックスですねあれがインデックスだった

わかりやすい後々そこはできればいいそうですね今だからそんなことは忘れてとにかくでかいSQLをビビらず触れるようになるっていうのが最初のステップかな何行ぐらいだったんですかそのでかいSQL何行って言われると開業のタイミングで変わっちゃうんであれなんですけど文字数で言うと1万文字から2万文字ぐらいでしたねSQLだけですかはい

関数ですごい分岐されてたんだね条件分岐がそのSQLを作る関数自体は結構4桁クラスの長さがありましたね4桁行のクラスの長さがあってそれによって生成されたSQLは条件によるんだけど1万から2万文字でしたでもそれも本当に基本的なセレクト

from テーブル名join で何個もテーブル結合してwhere ですっごい長くてorder by もっと長くてみたいな感じでしたねそれを読み解かなきゃいけない現場でした?いや関係ある箇所だけで大丈夫だよ例えばだけど今回だったらそこで検索で取れる結果の順番をちょっと

ルール変えたいみたいなとこであれば別にオーダーバイのとこだけ見ればいいしあーなるほど引っかかる求人の種類変えたいってことであればウェアのとこ見ればいいしっていう感じでなんかその関係ある部分だけでよかったかなって思いますねなるほどうんわざわざ全部読まないし読んでらんないっすよね読んでらんないしまあ別に読まなくてもいいと思う読むに差し支えなきゃそうだね

てか読まなくても大体そもそもやってることはセレクトとかそういう命令でわかるからあんまりその詳細の部分知らなくてもいいかもなるほどですねわかりましたそしたらでかいSQLに現場でなれろっていうところですかねまずは量じゃないなるほどですねっていう感じですねSQLははいちなみにSQLって何の略なのこれはですね当てていいですかいいよすごい

言ったもののスマートスマートクエリラングエッジ惜しいクエリラングエッジはクエリラングエッジはね合ってるねスーパースーパークエリラングエッジすごそうだなスーパーではないですねちなみにSQLはなんかの略じゃなくてSQLって呼ばれてるって説もあります

あ説もあるんですねはいただなんだっけなストラクチャードクエリランゲージとかのから来てるっていう説もあった気がするなるほどそもそも略じゃないよっていうパターンかまあストラクチャーなんとかっていうパターン諸説もある諸説ありだねこれはもともとは多分ストラクチャードクエリランゲージだったんでしょうけどそもそもなんかの略じゃないよみたいな説もあるんだよね略の方がありがたいですからなんか

確かにそうだよねちなみにこれも外国とかだとスイクエルとか言われてるらしいですよかっこいいそういう言い切ってますかスイクエルスイクエルあんま日本でその言い方する人いないけどね戦うスイクエルのはい略がSQLらしいほんと

外国ではSequelって呼ばれててはいってことは外国人がSequelって呼んでるものはSQLと書かれてないってことですか?えっとね元になってるのがSequelってものでそういう言語があったらしいのSEQUELであーなるほどでそれはSEQUEL自体がStructured English Query Languageの略らしくてうーん

それを元に作られているのがSQLみたいなことを書いてますね超SQLだ逆なしでもサイトによっては普通にストラクチャードクエリランゲージのやつから来てますよっていうサイトもあれば一応国際標準としてSQLは何かの略ではありませんっていう回答もありますねうーん

まあだから普通に落ちない感じになってるねどこに落ちてもまあ一応由来はストラクチャードイングリッシュクエリランゲージから来てるっぽいあってよかったその言語はSQL的な感じだったんですかねやっぱどうなんだろうねどうせ出てこないから大丈夫そうですねまあちょっと何か知ってる方いたら

お便りくださいすっごい難しいの来そうだけど大丈夫かなすごい詳しい専門的なやつ来そうこんな感じですかっぽいですねなのでこれからSQLは多分筋トレに近いと思うんでSQL筋を鍛えてなるほどバリバリに活躍できるデータベーススペシャリストになってくださいはい紙まくり出したねはい

じゃあ1000本ノックSQLやっていきますドリル?ドリルじゃあおすすめのいいっすね書籍?はい個人的にはSQLはあんまたくさんやってないんですけどSQLアンチパターンこれ僕結構好きですねあれ出た名著あんまり知らない俺でも知ってます本当?くらいの白い表紙でハンマーハンマーでねじ込んでるやつはい

あれねいいっすよアンチパターンだよって感じですよねあれのいいところは本当に力技でやると生み出してしまう構造とかをアンチパターンとして取り上げてくれてるので最初の頃に引っかかりがちな罠とかを知ることができますねしかも結構読みやすいと思うあれをそうなんですね僕も持ってはいる温めてる?温め中ね温めれば温めるほどね

効果出るからねなんかそんな気本当にそんな気しててもちろん現場でSQL実際に書いたりとかそういうタイミングがあった後にやると響くんじゃないかなって思い込んでますそれはあるそれはあると思います中級者向け

初心者寄りではあるんですけど初心者寄りではないねSQL知ってる前提で書かれておりるんで最初のステップとしては適切ではないですねアンチパターンですもんね知っててそれはダメだよってあとはこれも基礎知ってる前提ではあるんですけど達人に学ぶSQL徹底しないでしょかなあれはすごいですよあれもよく見ますね調べると

僕まだ1章しか読んでないんですけどいきなりスイッチかなから取り上げててスイッチに入るの?スイッチだっけ?ケース文かケース文を使った特殊なクエリからいきなり取り上げててこれはなんかすごそうだって思った記憶がある確かに徹底的に至難されそうなので個人的にはこの2冊はすごく

了承なんじゃないかなと思ってますどっかのタイミングでちゃんとやりたいですね進めしよう先ありがとうございますでは皆さんSQLマスターに向けて頑張っていきましょうまた来週バイバイ

宛先はそれではまた次回