00:12
ITエンジニアの雑談駆動開発部。 この番組は、同い年、若手エンジニア2人が、技術のこと、キャリアのことを、等身大のまま語り合っていく番組です。
成長中の2人が、学んだことをリアルタイムでお届けします。 そして、使用書なし、テストなし、雑談だけで駆動していきます。
ITエンジニアの雑談駆動開発部、始まります!
イエーイ!やっとここまで来た!
やっと始まれたよ!笑いすぎちゃったね。
ちょっとなかなか始められなかったんだけど、やっと始まりましたね。
どうもお願いします!
今日なんですけど、前回に続きというか、同じような分類の話で、SQLの文法とか、実際の書き方について話していこうと思います。
ありがとうございます。
以前なんですけど、SQLはデータベースっていうデジタル上の倉庫に、作業をお願いするための依頼書みたいなものって話をしたんですけど、今回はその依頼書の書き方を説明します。
まずは、依頼先のデータベースっていうのが、どんなものなのかっていうのをざっくりイメージできるように、簡単に説明させてください。
データベースっていうのが、Excel使いますよね?
使います。
Excelの表を想像すると、個人的に分かりやすいなと思って。
はい、想像してくださいね。
はい、想像してます。
例えば、一番上ですね、表の一番上に、商品名価格っていう見出しがあって。
商品名価格。
はい。っていうのが、A1とかにある。
A1、はい。
置きました。
ありがとうございます。
で、商品名の下にリンゴって書いてあって、価格の下に200円みたいな。
で、その下の行にまたバナナ150円みたいに並んでいる商品一覧を想像してみてください。
よくあるExcelの表ですね。
A列が商品。
そうです、A列が商品。
で、B列が価格。
そうそうです。
で、一個目にタイトルみたいな感じで項目がある表ですね。
で、データベースってこういう表と同じで、こういう表をテーブルって言ったりします。
テーブルですね。
はい。
で、これエンジニアの方とか聞いたことあるかもしれないですけど、商品名の列、価格の列のような縦の列をカランって言います。
03:00
カラン。
カラン。
C、O、L、M、N。
そうそう、そんなやつ。
で、なんかその縦が何を表しているかみたいな、タイトルみたいな感じですね。
見出しか、みたいな感じですね。
で、リンゴ200円みたいに横にその見出しが何を表しているかみたいに書いたやつをリンゴ200円みたいなやつですね。
横に並んだ1件分のデータをレコードって呼びます。
はい。
ちなみに表の縦は列で横は行っていうように実は決まってます。知ってましたか?
なんか基本情報とかITパスポートとかでなんか覚えさせられた記憶がありますね。
そう、なんか言うらしくて、縦は列で横は行っていう。
なんで縦イコールカランで横イコールレコードって感じです。
で、これ覚え方なんですけど、自分は漢字で書いたときに列って漢字はカタカナのリみたいなやつ入ってるじゃないですか。
列っていう漢字に。
で、リみたいな部分とか全体的に縦に長いなみたいな、漢字自体が。
なので縦に長いので列、縦みたいな覚え方。
そうやって覚えてるんだ。
職場なんか覚え方があって。
あつい聞かせて。
言わなくていいの?
もう一回言って。
はいはい。
で、行って漢字は横に長いパーツ多いから、なんか横行みたいな漢字が一番多い。
横の、行くっていううちの右側とか横に横にってこと?
そうそうそう。
なるほどね。
なんか横に長いパーツ多いなってことで、自分はそれで覚えました。
すごいな。なんかそういうのあるよね。
あります。
なんか方向、イメージは分かる?なんか。
僕はそれで言ったら漢字の10を書くんですよ。
漢字の10。
漢字の10を書き順って横書いて縦書くじゃないですか。
はい。
で行列って言うじゃないですか。
あー。
行列で覚えてます。
覚えやすいかも。それもありだ。
漢字の10を思い浮かべて行列で。行、横、列、縦。
で、いつも言ってます本当に。
それもいいかもしれない。
なんか絵的なイメージで覚えたい人、語呂合わせで覚えたい人って感じで好きな方を選べばいいと思いますね。
これITパスポートでね、出るかな。
あ、そうなんだ。
確かに。
で、さっき言ったやつなんですけど、表がテーブル、列が絡む、1件分のデータをレコードって言います。
はい。
で、データベースにはそういった商品テーブルとか顧客テーブルなどの情報の種類ごとに表を作れます。
で、そして必要に応じて別々の表の情報を結びつけることもできます。
06:03
便利。
そう。なのでリレーショナルデータベースって言ったりするんですよね。
おー、リレーショナル、関係。
その各々のテーブルを関連付けるってことでリレーショナルデータベースっていうらしい。
はい。で、この表の中のデータを探したり、レコードを追加したり、書き換えたりするための言語がSQLです。
今回の。
そうですそうです。なのでこの表ですね、テーブルっていう中からデータを探したりいろいろ操作できるのがSQLです。
はい。
では、データベースのイメージを掴めたところで、具体的な文法を話しません。
話してくださいよ。話さないの?
話しません。
なんだよ。
今回本当に説明しないんですけど、まあしないんかいって話じゃないですか。
ほんとだよ。
ですよね。
セレまで言いかけたよ俺は。
ですよね。
いや、でも今日SQLの書き方を説明しようと思ってここに来たんですよ。
はい。
でも、この英単語を書いてとか、その次にテーブル名を書いてって伝えても、今の時代こそ細かい書き方ってその都度AIに聞けばよくないって思う人多くないですか。
正直、チャピルかクロルほうが早いって思う人すごく多いと思うんですよね。
いつも聞いてます。
そう、特に自分たちと同じ世代、結構まだルーキーだったり若手の世代とかだとすごいAI使ってると思うんですよね。
なので、そういうことをこうやって言葉で教えてもらうより、自分で生成AIに聞いたほうが早いなって思う人かなり多いと思うんですよね。
だから、そういうのもあって、自分は最初から全部暗記する必要はないと思ってます。
中野さんはどうですか。
覚えたい。
はいはい。
けど、優先順位は高くない。
ぐらいかな。
そうですよね。
でも、自分が強く言いたいのが、だからってSQL、その他の技術も勉強しなくていいという話では絶対にないと思います。
なんでかっていうと、AIってこうしたいってちゃんと聞けたら書き方を教えてくれるんですけど、
自分が何をしたいかっていうのは自分で考える必要があるんですよ。
はい。
ですよね。
間違いない。
聞くこと決まってないと、
本当にそう。
AIは答えることすらできないですよ。
09:00
本当だよね。
自分が何を聞きたいっていうのが分かってないと、そもそもAIが答えてくれないんですよね。
例えば、商品を安い順に並べたい。SQLでどう書くのって聞いたら書き方を教えてくれる。
でも、そもそもSQLで並び替えができるって知らなかったら、SQLでやってみようって思いつかないんで途方に狂っちゃうんですよ。
だから、まず大事なのは文法を丸ごと暗記するってことよりも、その技術で何ができるかを知ることが今の時代大事だと思ってます。
それで大丈夫なのって不安になる人多いと思うんですよね。
でも、自分もすごくAI使ってプログラミングもするしSQLも書くんですけど、よく使う書き方とか大事な文法は業務の中で使っているうち、自分で実装していくうちに自然と覚えます。
何回も書くから。
だから、まず最初は聞いて、使っていくうちに覚えていく感じ。
もちろんなんですけど、AIの答えが自分のやりたいことと合っているかっていうのを確認が必要です。
ちゃんと自分のやりたいことがマッチしているのかなって感じで。
そのためにも、書き方の暗記とは別に何をしているかを理解する勉強は大事なんですよね。
なので、ここからは文法の代わりにSQLやDatabaseではこんなことができるよっていうのを自分が知っていること、大事だと思うことからざっと紹介していきます。
ありがとうございます。
ありがとうございます。
で、気になるものがあったら一度再生を止めて、それこそAIに聞いてみてください。
ちゃぴってくろってください。
はい。
で、じゃあ説明していきますね。
まず1個目が並べ替え。
ちょっとさっきも出てきましたね。
商品の価格を安い順にしたり、注文を新しい順にしたりできます。
ちなみにオーダーバイみたいに書きますね。
オーダーバイ。
オーダーバイ。
見たことある。
よく現場でも聞きます。
オーダーバイ、オーダーバイって言ってますね。
で、次に集計。
これもちょっと話したから。
商品の件数を数えたり、売上の合計や平均を出したりできます。
で、ちょっと応用すると月ごとの売上とか、商品カテゴリーごとの売上のようにグループに分けて計算することもできます。
こういうこともできるんですね。
で、それから別々のテーブルの情報をつなげる結合、ジョインという機能がありますね。
ちょっと苦手意識がある人もいるかもしれない。
そんな顔しちゃった。
ちょっと苦しい顔になっちゃいますね。
これなんですけど、例えば注文テーブルに会員番号と注文日が入ってて、顧客テーブルには会員番号と名前が入っているとします。
12:08
で、この共通の会員番号を手がかりに、同じ会員番号のデータを横につなげるのがジョインです。
例を出したら分かりやすいかなって思うんですけど、
例えば注文テーブルの101番の人が10月1日に注文したっていう情報に、顧客テーブルの101番は田中さんっていう情報を合わせて、田中さんが10月1日に注文したって分かるようになるかもしれない。
分かります?
101番で結びつけたの?
そう、101番で紐付けたの。それがジョインですね。
はい。
で、ここで自分もこれ聞いたとき思ったのが、最初から一つの表でよくねって思ったんですよ。
ああ、確かに。
最初から田中さんが10月1日に注文したって情報を一個のテーブルに入れとけばいいじゃんって思ったんですよね。
まあ、できなくはないもんね。
全然。
できますできます。
でも、ちょっと考えてみてほしいんですけど、田中さんが10回注文したら、同じ名前を10回テーブルの中に保存することになるんですよ、一緒になったら。
田中さんが10月1日に注文した、田中さんが11月2日に注文した、田中さんが5月5日に注文したみたいな感じですね。
はい。
もし田中さんじゃなくて伊藤さんだったってことが発覚したら、全部名前の訂正するってなったら、
うん。
例えば田中さんってやつが10個データが保存されたら、10個全部伊藤さんに変えなきゃいけないんですよ、一個一個。
はい。
めっちゃ大変じゃないですか。
うん。
そこで名前は顧客テーブルっていうので管理して、注文には会員番号と注文日を記録します。
そしたら101番が10月3日に注文、101番が11月1日に注文ってなって、101番の名前が変わっても顧客テーブルのデータを見て、101は誰かな。
あ、田中か。伊藤に変えようって。顧客テーブルの田中を伊藤に変えたら、全部もう一個の注文テーブルのが書き換わるの分かります?
うんうん。便利。
そう。一個変えるだけで全部反映できるんですよ。
綺麗だ。
そうそうそう。
気持ちいい。
すごい効率的。
算数みたいな感じだよね。
あ、そうそうそう。変数か。
あ、変数だ変数だ。間違えた変数。
変数か。
変数みたいな感じ。なので最小限の変更で最大限に全部反映できるんですよ。
ちょっとジョインの苦手意識なくなったんじゃないですか。
15:00
ジョインしたくなってきちゃった。
結合?
うん。結合したくなってきちゃった。
で、なんかレフトジョインとかイナージョインとかある?
ですよね。
それ嫌だ。ライトジョインとかレフトとかなんかライトだかイナーだか知らないけど。
レフトジョインの話なんですけど、
例えば、注文テーブルに10月3日に注文した15番さんがいるとするじゃないですか。
でもそれに紐づく、でそのデータだけあるとして、
で顧客テーブルには23番っていう会員番号の、
そうですね、佐藤さんがいるとするじゃないですか。
そしたらどっちも紐づいてないですよね、15と23。
で、レフトジョインだとそのどっちかを消えることはなくて、
例えば15番でしたね。
15番の10月3日に注文した名前がない人っていうレコードができて、
でもう一個に注文したことがない佐藤さんっていうレコードが入るイメージ。
あーはい。
なので、空欄がある感じですね、絡むに。
でもイナージョインだったら、合致するものがなかったら消しちゃいます。
あーそうなんだ。
そうそうそう、っていう違いがある。
なので、レフトだったら全部残るけど、イナーだったら消えるやつが出てくる、みたいなイメージですね。
で、これがジョインの話になるんですけど、
それ以外にも前ちょっと触れた通り、データの追加、更新、削除とかもできたりします。
新商品を登録したり、価格を変更したりする操作ですね。
はい。
ただ、更新や削除は対象の視点間違えると関係ないデータまで変えてしまうので、
何を対象にしているのかの確認とかめっちゃ必要ですね。
で、データベースの仕組み、今度はデータベース側ですね。
もう二つだけ紹介させてください。
一つは、これも聞いたことあると思います。
トランザクション。
トランザクション。
そうそう。
基本情報だ。
資格取ったからね。
あ、そうか。
僕、資格取ったからね。
よく聞くやつ、トランザクション。
で、これなんですけど、いくつかの処理をひとまとまりとして扱う仕組み。
例えば誰かにお金を送るときに、自分のお金だけ減って、相手のお金が増えなかったら困りますよね。
困っちゃう。
なので、システムトランザクション使うと、自分のお金を減らすと相手のお金を増やすっていうのをセット。
一連拓生にして、両方成功したら確定する。
途中で失敗したら変更を取り消すみたいに、処理をひとまとまりにして扱うことをトランザクションって言います。
ですね。
もう一つは、これも苦手意識多い人多いんじゃないですかね。
18:02
インデックス。
インデックス。
これはあんまり分かってない。正直。
ですよね。これもちょっと複雑で、本の作品みたいにデータを探しやすくして検索を早くするための仕組みですね。
ただ、つければ何でも早くなるわけではないので、まずは検索が遅いときに検討できる仕組みがあるってぐらいに知っておけば大丈夫です。
インデックスを軽く話すんですけど、普通だったら、インデックスってカラムに貼るんですよ。
カラムに設定するんですけど、インデックスが貼ってないときに検索をかけるときって、1件目からガーッと見ていくイメージなんですよ。
1行目、2行目、3行目、4行目、5行目って見ていくんですけど。
全部、操作内?
操作内です。
でも、インデックスを貼るとどうなるかっていうと、インデックスを貼ったカラムは、例えば100レコードの情報が入っているとして、
インデックスを貼ると、1から50のデータはここにあって、51から100のデータはこっちにあります。
どっちか選んでね、みたいな感じに出るんですよ。
で、今回検索で取りたいのは1から50までのデータだなってなって、1から50までの方に入るんですよ。
そしたらもうこの時点で半分選択肢捨てれますからね。
で、1から50までに入ると、今度は1から10、11から20、21から30っていうような区分けされてるんですよ。
あなたが欲しいのはどの区分けに入ってますか?みたいな感じで、
あ、今回欲しいのは11だったなって思ったら、11から20の区分けの中に自分の探したいものがいます、みたいな感じで入る。
はい。
で、そんな感じでやったら、操作でするのめちゃくちゃ早くないですか?
はいはい。
毎回同じになるよね。だいたい同じくらいになる。量が多くても。
そうですね。
みたいに聞いたことある気がする。
だって最初100だったのが50になって、半分半分半分みたいな。
ですね。
なので、確か、折り紙を…
あ、聞いたことある。
7回折ったら宇宙に届くみたいな。
月届くと月行くみたいなやつ。
データが多ければ多いほど、指数関数的にどんどん効率的になるみたいに、
すいません、自分もあんま言葉にできてないんですけど、
データの量が増えれば増えるほど早くなるイメージがあります。
そのインデックスの効果がある。
だから目次みたいな。
あ、そうですそうです。
作員か、作員ってさっき言ってた。
そうそうそう、みたいな感じですね。
で、いろいろ紹介させてもらったんですけど、
サイドになりますけど、全部完璧に覚えなくていいです。
はい。
今後、例えば月ごとの売上を出したいって思った時に、
21:01
そういえばSQLのまとめて計算できたよな、みたいな感じで思い出せれば、
それが調べるきっかけになります。
で、AIに書き方を聞いて、わからない部分はここは何をしているの?って聞いて、
そして実際に動かして、欲しい結果になっているか確かめる。
っていうような勉強法、進め方がいいなと思います。
で、これSQL以外のプログラミング言語を勉強する時も同じだと思ってて、
その技術を使って何ができるかっていうのをまず知る。
で、必要になったら調べて使う。
使いながら理解していく。
これがAIのある時代のエンジニアの戦い方なんじゃないかなって思いますね。
それで思ったのは、俺たちエドワード・エルリックだなって。
エドワード・エルリック?
そうそう。鋼の錬金術師。
見たことありますか?
見たことはないです。
あれですよね。ちょっと上の世代ですよね。鋼の錬金術師。
でもさっき調べたんで、言いたいことは分かるかも。
ありがとうございます。
鋼の錬金術師って錬金術っていう魔法みたいなやつを使って、
兄弟がいろいろ冒険していくみたいな、そういうダークファンタジーの名作なんですけど、
魔法みたいなのを使うために魔法陣みたいなのを書くんですよ。
その技を出すために魔法陣みたいなやつを錬星陣って言ったりするんですけど、
書いてあった。
錬星陣っていうのを地面とか壁とかに書いて、手をパチッとして、
その錬星陣に触れるとその術が使えるみたいな。
だから小学校が中ぐらいの中で、
書いて手合わせてそれに触れると術がバーって火が出たり、
いろいろするみたいなのがあるんですけど、
それに出てくる主人公のエドワード・エロリックって、
この魔法陣みたいな錬星陣ってやつ書かないんですよ。
書かなくて、手合わせてどっかに触れただけで、
魔法がバンバン出せる。
ずるいじゃん。
魔法陣とか書かずにパチッ、バーン、パチッ、バーンみたいな。
ずるい。
みたいなことができて、
それも漫画読んでみたら分かるんですけど、
心理の扉ってやつが出てきて、
心理の扉?
それに触れてしまった、見てしまったから、
全て理解しちゃって、魔法陣なんていらなくなったみたいな感じ。
24:03
そのエドワード・エロリックって、
頭の中でやりたいことを明確にイメージしたら、
錬星陣書かなくても形にできるんですよ。
術使えるんですよね。
でもエドワード・エロリック自体も、
何を作る、何を発動するかっていうのは、
頭の中で全部理解してるんです。
どんな仕組みなのか理解してるから、
魔法陣必要ないんですよ。
なので、エドだって分からないことは錬星できない。
エドって実は、
そんなずるいチートキャラみたいじゃないですか。
でも実は国家錬金術師っていう、
めちゃくちゃ勉強しないと慣れない魔法使いみたいな感じ。
めちゃくちゃ勉強してる。
なるほどね。
じゃあまだ許すよ。
魔法陣書かないけど、
魔法陣書けたとしてもめちゃくちゃすごい錬金術師なんですよ。
めっちゃ勉強してるからこそ、
その真理の扉を見た後も無双できます。
ちゃんと勉強してるんじゃん。
そう。
なので自分たちこそ、
もうAIっていう真理の扉を見ちゃってるので、
自分たちAI使うと錬星陣書かなくていいんですよ。
セレクトとかオーダーバイとかいちいち覚えなくていいんですよ。
なるほど。
で、そのまま、
AIに聞いてクリックでいいんですよ。
これだけでいいんですよ。
ほんとに手合わせよう今度。
それだけで錬星できる?
スケアル書くときに手合わせることにします。
錬星できるかもしれない。
なので何を作るか、
エドみたいに何を作るかを明確にイメージして、
それを形にしてもらう。
っていうのがこれからの戦い方なんじゃないかなって。
俺たちはエドワードエルリックだって思いましたね。
こうします。
こっちで手合わせる。
こうします。
そしたらプログラム錬星されるんで。
もうシステム、手合わせたり指パッチンしたら錬星されるんで。
剥がれんじゃないですか。
この時代は剥がれんなんだよ。
エンジニアは錬金術師なんだよ。
なので今日はそういうことで、
SQLの文法を説明する回と見せかけて、
暗記折り、まず何ができるかを知ろうというお話でした。
なるほど。ありがとうございます。
ありがとうございます。
