2023-06-29

「スッキリわかるSQL入門」読書会レポート vol.7

読書会

株式会社リゾーム技術部システム開発第4グループの平松です。今回は「スッキリわかるSQL入門」読書会の第7回のレポートです。

「スッキリわかるSQL入門」の過去のレポートや他の読書会のレポートはカテゴリーでまとめていますので、こちらからご覧いただけます。

tech.rhizome-e.com

読書会の題材

前回に引き続き「スッキリわかるSQL入門」を題材としています。

7回目レポート

7回目は第8章「複数テーブルの結合」のレポートになります。参加者は4名でした。

それぞれの感想・意見交換

「リレーショナル」の意味

基本情報の勉強でやったところ
テスターは自分でテーブルを設計する機会はないが、テスト用に各テーブルを結合して抽出して…とやっていると、根本的な設計の大事さはなんとなくわかる
データの関係性によって、どのようなテーブルにするのかは分かれる
どのテーブルに外部キーを持たせるかは目的によって変わる
テーブルを複数持てることの恩恵が改めて分かった
単一のテーブルでデータを管理するのは考えたくないな…。絶対どこかで不整合が生まれそう
複数テーブルに分けるメリットは座学で習うだけだとあやふやだったけど、実際に業務でSQLを触っていくうちに感覚として納得した

テーブルの結合

SQLで一番初めに躓いたところ
初めて使った時は表計算ソフトっぽいというのが頭の中にあったため、結合のイメージがしづらかった覚えがある
初めて習った時は「おおー」となった。データベースを扱ってるという実感があった
結合はイメージが湧き難いので、書籍では紙工作で結合を体験できるようになっていて初学者には非常に分かりやすくて良いと思った
当たり前のことだけど、結合結果を頭の中でイメージするのは難しいので、実際に結合結果を見て理解するのが確実
結合も種類があるため、必要なデータによって内部結合を使うか、外部結合を使うか変わってくる
条件を満たしている行に繋がっていくイメージはうまくできている
製品内部にも必ずと言っていいほど使われているし、テストでも使う
テーブルの結合は業務でよく使う
「INNER JOIN」を省略して「JOIN」と書くことは滅多に無い

結合条件の取り扱い

完全外部結合（FULL OUTER JOIN）は使ったことがない
例で出た「WHERE NULL = …」みたいなことはさすがにやらないが、「この書き方だったらNULLはどうなるか」はやはり気を付けないといけないところ
INNER JOIN と LEFT JOIN の2つを覚えておけば大体の状況に対応できそう
内部結合の動作がややこしい
- 内部結合の説明を読んだ後だとLEFT JOIN, RIGHT JOIN, FULL JOINの動作に納得した
結合相手が複数行の場合、結合前より行数が増えるというのが混乱する原因な気がする
INNER JOIN, RIGHT JOIN, LEFT JOINとかの違いはベン図で考えるのが一番理解しやすかった
JOINにいろいろ種類があるのがややこしい
- 特に省略表記できるのが逆に厄介だと思う
- 個人的には混乱しがちなポイント
業務では結合条件の列がNULLであってもデータを取得したいことが多いので主に LEFT JOIN を使う
混乱を避けるため RIGHT JOIN は使わず、LEFT JOIN のテーブルの順番を入れ替えるようにしている
- そういうルールで運用しているチームは多いイメージ
FULL JOINじゃなくてUNIONを使うことのほうが多い
個人的にINNER JOIN, LEFT JOIN, RIGHT JOINには「OUTER」は付けないが、何故か完全外部結合のときだけ「FULL OUTER JOIN」にしてしまう

結合に関するさまざまな構文

カラム名にテーブル名がなくてエラーになるのはよくやる（エディタの下線に助けられている）
3テーブル以上やサブクエリを結合すると、どうしても見づらくなるので、インデントやコメントをしっかりつけたい
特定のカラムだけを抜き出したテーブルを結合させたことがある
同じテーブルを結合するのはしたことないかもしれない
自己結合で同じ家計簿同士を繋げたいことはあるのか？と考えながら読んでいたらテキストの例を見てなるほどなってなった
3テーブル以上の結合や、サブクエリ結果との結合、同じテーブル同士での結合は使う機会はなかった
同じテーブルを結合するのは自分で書いたことはないがPull Requestなどでよく見る
基本的に結合する場合は、テーブル名を明示的に指定している
- 列名を記述する際もエイリアス名を必ず書くようにしている
- 個人的にその方が読みやすいし、自分の想定していないテーブルの列が参照されるような想定外の挙動になることを防ぐことができる
副問い合わせの結果を結合するのはよくやる

まとめ

今回は、RDBMSの目玉の結合に関する章でした。意見交換の場でも実際の業務に関わる話が多かった印象です。結合について学ぶことでSQLでできることの幅が一気に広がると思います。結合はよく使う機能ですが私自身も知らなかった使い方があったので今後、SQLを触る際に活用していきたいと思います。

次回は、第9章「トランザクション」になります。次章から第三部「データベースの知識を深めよう」の内容になっていきます。

2023-06-22

「スッキリわかるSQL入門」読書会レポート vol.6

読書会

株式会社リゾーム技術部システム開発第1グループの小田です。今回は「スッキリわかるSQL入門」読書会の第6回のレポートです。

過去のレポートはこちらからご覧いただけます。

「スッキリわかるSQL入門」読書会レポート vol.1 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.2 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 3 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 4 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.5 - リゾームのテックブログ

読書会の題材

前回に引き続き「スッキリわかるSQL入門」を題材としています。

6回目レポート

6回目は第7章「副問い合わせ」のレポートになります。

今回の参加者は6名でした。

参加者の感想・意見まとめ

7.1 検索結果に基づいて表を操作する

「副問い合わせ」より「サブクエリ」という呼称の方がよく使う。
副問い合わせのSELECT文自体は単純な構造だけど、入れ子にすることで複雑な集計をさせられる。
- 括弧とインデントでサブクエリのブロックを意識することと、サブクエリの結果が値に化けるというイメージは大事。
- クエリが複雑になるほど、可読性を意識して書くのが大切になってくる。
安直に副問い合わせを書いてしまうと可読性が下がってしまったり、パフォーマンスに影響があるかもしれないのでイマイチだけど、業務ではよく使う。
- 場合によってはJOINの方がパフォーマンスが良いケースもある。
- 副問い合わせとJOINどちらがパフォーマンスが良いかについては、RDBMSの種類によって速度に大きな違いが出るのでどちらが良いか一概には言えないらしい。SQLのパフォーマンスチューニングは奥が深い...。
（コラムについて）データ構造の基本をスカラー、ベクター、マトリックスと呼ぶのは初めて知った。
- 3パターンに分けて勉強するのは分かりやすくて良いと思った。

7.2 単一の値の代わりに副問い合わせを用いる

1つの値になるから比較演算子を用いて比較できる。
集計関数と合わせると効果的に使えそう。
副問い合わせの内容が長くなりがちで、かつそれがSELECT句の途中に入るので可読性の工夫が要ると思う。
INSERT時、IDを採番する際にレコードのIDに+1した値をセットする副問い合わせを書いたりする。

7.3 複数の値の代わりに副問い合わせを用いる

複数の値のため比較にはANYやALL、INを用いる必要がある。
テーブルに直接値が入っている場合は使えそう。
「NOT INまたは<>ALLで判定する副問合せの結果にNULLが含まれると全体の結果もNULLとなる」
- NULLに注意が必要！NOT INの動作は罠だなぁ。
- 普段NOT INを使うことはあまり無いが、いざという時嵌りそうなので覚えておきたい。
- NULLを除外する方法：
  - サブクエリのWHERE句でIS NOT NULLを指定する。
  - COALESCEでNULLを別の値に置き換える。
ひねりの効いた使い方というか、演算子との組み合わせ方やNULLへの配慮など考えないといけないが使いこなせると便利だと思う。

7.4 表の代わりに副問い合わせを用いる

製品の検証作業時に分析結果の確認などでよく使うパターン。
FROM句やINSERT文では本当によく使う。特に複数データ登録するときにINSERT～SELECT～は超便利。
- INSERT-SELECTは本にも書かれているけど、厳密には副問い合わせではない。INSERTがサポートしている特殊な構文。複数のテストデータを用意するときに使った記憶がある。
- INSERT文の特殊用法は読みづらいけど、1塊ごとに考えていくのを意識していきたい。
- FROM句で長い副問い合わせを書くと、書いた本人でも読みにくいなと思うためあまり書きたくない。最近WITH句を覚えたので、できればそっちを使ったりしていきたい。
外側のSQL文の列を使う相関副問い合わせは使う機会はあまりなさそう。
- 相関副問い合わせなんてものがあるんだな…。同じような書き方だけど内部的な動きやコストが違うのは罠だな。複雑な処理を書いていると、気づかないうちに相関になっていた、なんてことがあったりするのかな。
- 大体はテーブルで関連付けをしてるからJOINを使うほうが多そう。
エイリアスを付け忘れて中々エラー解決できずに泣いたのはいい思い出…。
- ベンダーによっては必須ではないが、副問い合わせの結果には必ず別名を付けるのがよさそう。
これも複雑になるとあとで見直すとき大変なので、インデントやコメント大事だと思う。

まとめ

書籍では副問い合わせの検索結果が単一の値・1次元配列・表の3つにパターン分けした上で学習を行うよう章立てされており、参加者からも「理解しやすい」と好評でした。

参加者から多く出た意見としては、副問い合わせは便利な一方で可読性やパフォーマンスが落ちることがままあるため、使用方法やインデントに十分注意する必要があるというものでした。

副問い合わせは私自身も使う機会が多いのですが、やはり度々パフォーマンスが問題になったり構造が複雑なクエリになっていることがあるので、JOINやWITH句を用いることでより簡潔でパフォーマンスの良いクエリにできないか都度検討するよう心がけたいと思います。

次回は第8章「複数テーブルの結合」です。テーブルの結合はSQLの肝となる重要な機能なので、しっかりと学習を行いたいです。

2023-06-14

「スッキリわかるSQL入門」読書会レポート vol.5

読書会

株式会社リゾーム技術部システム開発第1グループの岩﨑です。今回は「スッキリわかるSQL入門」読書会の第5回のレポートです。

過去のレポートはこちらからご覧いただけます。

「スッキリわかるSQL入門」読書会レポート vol.1 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.2 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 3 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 4 - リゾームのテックブログ

読書会の題材

前回に引き続き「スッキリわかるSQL入門」を題材としています。

5回目レポート

5回目は第6章「集計とグループ化」のレポートになります。参加者は6名でした。

それぞれの感想・意見交換

データを集計する

集計関数はすべての行をひとまとめに処理して、結果は必ず1行になる
単純に平均の計算とか合計値を手計算する場合も結果は必ずひとつの値で出るため、集計関数の結果は必ず1行になるのも納得
すべての行に対して集計を行うので、集計対象などの指定がある場合はWHERE句で絞り込みをしないといけない
「○○する関数ってないのかな？」とExcelと同じような発想で考えて調べることができるので、心理的なハードルは低い
同じようにSELECTの中に関数呼び出しを書いても、関数の種類によって動きが変わってくるというのは、改めて考えると特殊だ

集計関数の使い方

SUM, MAX, MIN, AVG, COUNT等の関数はよく使う
COUNT関数以外はほとんど使ったことがない。使っているSQL文を見るぐらい
- COUNT関数はデータ抽出する際に抽出数を把握するために使ったりする
Excelでも使うような関数ばかりだったので覚えやすかった
普段COUNT(*)ばかり使っていることもあり、COUNT(列)では指定した列がNULLの行は無視される仕様は知らなかった

集計に関する4つの注意点

集計関数の引数やNULLに関する取り扱いについての理解が曖昧だった
- 集計にNULLが含まれる場合の挙動は毎回不安になって調べてしまう
計算式をSELECTするという発想になじむのに時間がかかった、今はそういうものだと無理やり納得している
例えば「合計が～以上」という命令文を考えると、WHERE SUM(X) > 100みたいに書きたくなるかもしれない
結果表がデコボコになって、なんでエラーになるんだろう？　みたいな経験は何度かある。GROUP BYを使うときとか
- SQL学び始めの頃はよくハマっていた
MAX関数やMIN関数は文字列を指定しても使えることを少し前に知って驚いた
前章ではCOALESCEはISNULLで対応することの方が多そうという意見もあったが、たしかにCOALESCE関数だとISNULL関数よりも綺麗に記述できているような気もする

データをグループに分ける

業務内容によって、GROUP BYやHAVINGを使う機会が異なっている
「期間内のデータを、各ショップや会員が属する区分ごとに集計」という場面がすごく多いので、GROUP BYはおなじみ、というかこれなしではテストできない
GROUP BY内のカラムとSELECT内のカラムをそろえ忘れてエラーにしてしまうことが多かった
グループ集計の流れは今まで何となく理解していた状態だったのが今回、明確になった
HAVINGは使い慣れていなくてWHEREと混同してしまいがちなので覚えていきたい
- 集計前の条件がWHEREで、集計後の条件がHAVING
集計結果は処理の流れ的にWHEREでは絞り込めないため、HAVINGを使う必要がある
最初HAVING句を知らなくて苦労した記憶がある……

集計テーブルの活用

PostgreSQLではマテリアライズドビュー（マテビュー）という機能を使って集計テーブルを実現できる
- マテビューは実体を持たない通常のビューとは異なり、処理結果を保持しているため再検索なしで繰り返し参照できる。また、リフレッシュすることで最新の状態に更新が可能
最終的な結果を見るテストの立場ではあまり気にしたことがないかも……。とはいえ、知識としては持っておきたい
扱うデータの種類や規模によって、集計テーブルの更新頻度を調整するのが重要だと思った
- 頻度が高すぎると負荷がかかるし、低すぎると集計結果が古くなってしまうので難しそう
大規模な分析が必要なシステムだと複雑になったりしてメンテナンスが大変

まとめ

本章の内容はもちろん、前章で学んだ内容を振り返りつつ話し合いができたと思います。また今回もチームや業務内容が異なると、使用する関数等に違いがあることがわかりました。私自身SQLの学習を始めて1年ですが、未だにGROUP BYなどを使う際には混乱することが多いため、本章で学習した内容を活かして今後の業務を行っていきたいと思います。次回は第7章「副問い合わせ」です。

2023-06-09

「スッキリわかるSQL入門」読書会レポート vol. 4

読書会

株式会社リゾーム技術部システム開発第1グループの宮野です。
「スッキリわかるSQL入門」読書会　第4回のレポートです。

過去の記事はこちらです

「スッキリわかるSQL入門」読書会レポート vol.1 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol.2 - リゾームのテックブログ

「スッキリわかるSQL入門」読書会レポート vol. 3 - リゾームのテックブログ

今回の題材

引き続き、「スッキリわかるSQL入門」を使用しています。

今回から第Ⅱ部「SQLを使いこなそう」に入りました。
第5章「式と関数」を参加者で読み、感想などを話し合いました。

参加人数

今回は6人での読書会となりました。

参加者の感想・意見まとめ

5.1 式と演算子

式・演算子はよく使うというメンバーもいれば、普段の業務ではあまり使わないというメンバーもいました。また、以下のような声が挙がっていました。

別名は製品やDBMSによる。例えばSQLServerで列名を付けずに計算式のままにしておくと「(列名なし)」になる
テーブルの各行は一行ずつ順番に処理される。プログラマなら当然の発想だが、確かに初学者は戸惑うかも

5.2 さまざまな演算子

こちらも、使用頻度・よく使う演算子はメンバーそれぞれでした。
CASE演算子が紹介されていましたが、「使われているSQL文を見たことがあるくらい」という人もいれば「よく使う」という人もいたり……
また、 DBMSによって使用できる演算子が異なるケースについても多く発言がありました。

文字列連結は「||」とあるがSQL Serverだと「+」か CONCAT 関数、など

便利ですが、こういう注意点もあったり。

文字列連結の際には「+」をよく使うが、SQL Serverだと連結する対象がひとつでもNULLの場合、他に文字列があったとしても結果がNULLになってしまうため要注意（NULLはあらかじめISNULLで空文字などに置き換えておく）

5.3 さまざまな関数

こちらもメンバーによって使う機会・使う関数は様々…
そしてやはりDBMSによる違いが話題になりました。

検索して出てきた関数を使用できないということがたまにあった。難しいけど製品のドキュメントをなるべく見るように…
SQL Serverで使ってたあの関数と同じ関数がPostgreSQLに無いかな？無いわ…、みたいなことがあったりする

5.4 文字列にまつわる関数

こちらもメンバーによって（略）
よく使うというメンバーにとっては、この節に登場する関数はどれもおなじみですね…

コードとコードを連結するとか、郵便番号からハイフンを取り除くとか
（5.2で挙がっていた、文字列連結で「＋」を使う際はNULLの対処が必要ですが）CONCAT関数だとISNULL無しでも暗黙的に空文字に置き換わる

5.5 数値にまつわる関数

こちらもメ（略）
普段かかわる業務やDBMSによる差が話題になりました。

データ分析や金額計算をするアプリでは ROUND や TRUNC をよく使うのだろうか？
分析結果はたいてい何らかの四捨五入なのでROUNDにとてもお世話になる
SQLServerだとTRUNC関数は使えない。代わりにROUND関数
powerはべき乗の「べき」のことなのね。ﾊﾟﾜｰ!

5.6 日付にまつわる関数

こちらもメンバーによる使用頻度の違いはありましたが、特にSQL Serverユーザーによる「現在日時はだいたいGETDATE()」という声が多く聞かれました。

GETDATE()で日付取得してCONVERT関数やFORMAT関数で希望の書式に変形

5.7 変換にまつわる関数

この節で紹介されていた関数の中ではCASTをよく使うという声がありました。

数値型を文字列型に変換して連結する
演算子を使用する際、計算するデータ同士で型を合わせる　など

COALESCEはISNULLで対応することの方が多そう…とも。

全体を振り返って

関数はDBMSやバージョンによる差がやはり大きいようで、調べて出てきた関数や以前の業務で使っていた便利な関数が今使用しているDBMSにはない、といった経験が多く聞かれました。
また、現在携わっている製品・業務によって関数を使用する頻度、よく使う関数の種類が全く違うことも印象的でした。
普段見えない世界が見えるのも、チームをまたいだ読書会の面白さかもしれません。

2023-05-24

「スッキリわかるSQL入門」読書会レポート vol. 3

読書会

株式会社リゾーム技術部システム開発第3グループの岡部です。今回は「スッキリわかるSQL入門」読書会の第3回のレポートです。

過去のレポートはこちらからご覧いただけます。

書籍について

使用した書籍は「スッキリわかるSQL入門」です。

スッキリわかるSQL入門第3版 - IT入門書籍スッキリシリーズ (sukkiri.jp)

スッキリわかるSQL入門第3版ドリル256問付き！スッキリわかるシリーズ

作者:中山清喬,飯田理恵子
インプレス

Amazon

今回の学習範囲

今回読んだのは第4章「検索結果の加工」です。

参加者の意見・感想

今回は6名が参加し、お互いに意見や感想を共有しました。

検索結果の加工

検索結果の加工全般について、以下のような意見がありました。当たり前かもしれませんが、担当している製品や業務内容によって、使用するキーワードや頻度が異なってくるようです。

WHERE句の条件指定で済む場面が多いので、あまり使う機会が無い。重複の削除と並び替えをたまに使う程度。
テストでは、アプリ画面と同じ結果になるよう検索結果を加工することがある。
使ったことがない、あるいは初めて知ったキーワードもあった。

DISTINCT - 重複行を除外する

DISTINCTについては以下のような意見がありました。

時々使う機会がある。
会員の重複を取り除いたうえでデータをチェックしたり、会員数を集計することがある。
DISTINCTよりGROUP BYをよく使う。

ORDER BY - 結果を並び替える

ORDER BYについては以下のような意見がありました。今回学んだキーワードの中では最も使用頻度が高そうです。しかし、列番号による指定や順序保証に関して、新しい発見もありました。

プロダクトでもテストでも、大変お世話になっている。
列番号で並び替えの基準を指定できるのは知らなかった。
- しかし書籍にも書いてあるように、列の順番に依存してしまうので、できるだけ使わない方がよさそう。
- 主キーが連番かつ1列目にあるテーブルのデータを目視で確認するとき、SELECT * FROM table ORDER BY 1 DESC のように書くことはある。プロダクトでは使わない。
- UNIONなどの集合演算子を使う場合、単純に列名指定できない制約があるため、その際に利用することはある。
ORDER BY句を付けないと順序保証されない件は注意が必要。
- 大抵は主キーでソートされてしまうので、SQLの実行結果だけ見て安心してしまいがち。しかし実質的にはランダムであり、DBMSの実装に依存しているので、順番が重要な場面では必ずORDER BYを付けよう。
書籍には書いていないが、照合順序や型の関係で、思わぬ順番になることがあるので注意が必要。

OFFSET/FETCH - 行数を限定して取得する

OFFSET/FETCH句について、使ったことがない、あるいは知らなかったという方が多かったものの、各DBMS独自のキーワードを使って同様の処理を行うことは少なくなさそうです。

データ抽出の際は全件取得で問題ないことが多く、あまり使ったことがない。
LIMITを使ったことがある。
- PostgreSQLやMySQL等で利用できる。
TOPはよく使う。
- SQL Serverで利用できる。
- 逆に、SQL Server以外で使えないのを知らなかった。これが無いと不便に感じてしまう…。
- SELECT TOP (n) PERCENT * FROM table のように書くことで、上位n%を取得することもできる。

集合演算子

UNION（和集合）やEXCEPT（差集合）、INTERSECT（積集合）といった集合演算子について以下のような意見がありました。これらの中では、主にUNIONを使うことが多そうです。

集合演算子は全く使ったことがなかった。
UNIONを使った処理自体は時々見かけるが、自分で書いたことはあまりない。
UNIONしか知らなかった。EXCEPTとINTERSECTは使ったことがなかった。
EXCEPTは順番に注意。毎回ちょっと混乱する…。

まとめ

今回はSELECTで抽出した検索結果を加工し、目的に合わせて整形する方法を学びました。今まで使う機会があまり無かったキーワードはもちろん、ORDER BYのようによく使うキーワードに関しても、改めて体系的な知識を得ることができたと思います。

次回は第5章「式と関数」で、第II部に入ります。式や関数を用いて計算を行う方法を学びます。

2023-05-18

「スッキリわかるSQL入門」読書会レポート vol.2

読書会

株式会社リゾーム技術部システム開発第3グループの土井です。「スッキリわかるSQL入門」読書会の第2回レポートです。第1回目のレポートはこちらです。 tech.rhizome-e.com

読書会の題材

前回に引き続きスッキリわかるSQL入門を題材としています。

2回目レポート

2回目は第2章「基本文法と4大命令」と第3章「操作する行の絞り込み」のレポートになります。参加者は6名でした。

それぞれの感想・意見交換

基本文法と４大命令

SQLの基本ルール

SELECT, FROM, WHEREで行を分けて書いている
予約語は大文字で書いている
自分の中での予約語のルールとしては、予約語ではないものと判別しやすいように必ず大文字で書くようにしている
- 予約語には大文字小文字の区別はないけどチーム内でそろえたほうがいいだろう
Transact-SQL (SQL Server) だとセミコロンの使用が推奨されている
Transact-SQL ステートメントの終端記号。セミコロンは、このバージョンの SQL Server のほとんどのステートメントでは必須ではありませんが、将来のバージョンでは必須になる予定です。

引用元:Transact-SQL 構文表記規則 (Transact-SQL) - SQL Server | Microsoft Learn
- セミコロンが必須になれば既存のコードが動かなくなるから推奨のままなのでは？
複数のSQLを続けて書くときは後から読みやすくするためにも末尾にセミコロンを付けたほうが良さそう
文頭がかならずSELECTとかDELETEとかなので、セミコロンがなくても文末は判別できるからかあんまりつける意味を感じない。つけた方が処理が早かったりするのかしら？
- エディターが色を分けてくれるからセミコロンが無くてもだいたいわかる
所属チームではコメントは基本ハイフン2つで書いているイメージ
- ストアドには作成者とか作成・更新日くらいで、処理の補足説明等があまり書かれていないため毎回読むのにかなり時間がかかっている（ストアド仕様書と照らし合わせている…）

データ型とリテラル

型は知っていたが文字列の固定長、可変長それぞれの違いについて曖昧だった
どのデータ型を使えばいいのか？という部分がそもそもどういった型があるかも含めて調べながら進めている
データ型はいまだに戸惑いがち。クエリ実行してエラーになってはじめて気づくとかよくある。テスト業務では既存のテーブルを検索したり加工したりしかしないからよいが、作る立場だとデータ型はすごく気を使いそう…
「ダブルクオーテーションはSQLの文字列リテラルとして用いることは出来ません」
- 最初の頃は結構混乱していた覚えがある
文字列型はvarcharかnvarcharしか使ったことがない(SQL Server)
CHARとVARCHARが入り混じってる時はめちゃ混乱する…
- つい最近も連携されるCSVデータの項目にCHARとVARCHARが入り混じってた
最近だとCHAR型からVARCHAR型に変換する際に、後ろの空白をすべて取り除く必要があり記述が大変だった
- char varchar が混ざると半角スペースで埋まってたり、埋まってなかったりで後処理が大変だった

SQLの命令体系 /SELECT文 - データの検索/UPDATE文-データの更新/DELETE文-データの削除/INSERT文-データの追加

SELECT以外の他の3つはUPDATE SET, DELETE FROM, INSERT INTOみたいに固有の部分とセットで覚えていた
テキストの体系図が分かりやすかった。
ASはデータ抽出する際に項目名をそのままエクセルの表のヘッダーとかにするためよく使う
アスタリスクを使うとASで列に別名をつけれないのであまり使ってない
「SELECT * FROM」はデータベースの設計変更の影響を受ける危険性あって注意が必要
WHERE句忘れは油断しているとやりがち。UPDATEやDELETEを使うときは、あらかじめトランザクションを開始しておき、その中で動作確認するようにしている。そうじゃないと事故る…
UPDATE/DELETE時のWHERE句の付け忘れはマジで注意…（身に覚えあり）
- 前回も話に出ていたが、まずはWHERE句付けた状態でSELECTしてみて、更新/削除対象のレコードだけがSELECTされることを確認してから命令部を書き換えるのを徹底している（当然トランザクションもかける）
UPDATEとDELETEはそこだけ書き換えたら動くし要注意
- トランザクションかけたり、先にFROM～WHERE～を記述しておいたりすれば防ぐことが出来る
普段の業務では、他のテーブルを参照してデータを生成することが多いので、INSERT～VALUES～よりINSERT～SELECT～のほうがよく使うかも
FROMを先に書くとインテリジェンスが効く

4大命令をスッキリ学ぶコツ

検索系、更新系で覚えていたから既存系と新規系の分類方法は知らなかった
テキストが推奨する記述順には違和感があった
SQL、というかプログラミングはとにかく手を動かして覚えるのが一番早い

操作する行の絞り込み

WHERE句による絞り込み

SQL文を作成する際にWHERE句は欠かせない存在
取得したいデータの項目を並べたとしても絞り込みの条件をWHERE句で指定しないと意味のないデータになってしまう

条件式

対象となるデータを指定するためにWHERE句を使う
WHERE句は条件を指定
- 行を指定するのも本質的には条件
- テキスト内のINSERTで使えないのというのはWHERE句なしで列を指定しているからでは？
例である数値の足し算は書くとしたらSELECTになる

様々な比較演算子

比較演算子は数値か日付で使う
IS NOT NULLをよく使う。boolean型だったらIS TRUEとか
NULLの判定で、IS NULL/NOT IS NULL演算子を使うのはSQLの特徴。最初の頃は＝を使ってしまい期待とは違い挙動によくなったりした
NULLを比較演算子で判定できないのはなんとなく知っていたが、理由は初めて知った。
- 比較演算子は値同士を比較するもの。NULLは値ではないので、比較すると結果がUNKNOWN (TRUEでもFALSEでもない！)になってしまう
「条件式の結果はTRUE,FALSE,UNKNOWNの3つの結果がある」
- てっきりNULLもFALSEとして判定されてるとばかり思ってたが、厳密には違うっぽい
最初のころ「=NULL」と書いてしまった経験はある。「値ですらない」と今回読んで納得した
NULLの扱いは難しいし、出てきたら気を付けるようにしている
- そもそもNULLでいいのかとか
直近の業務で、NULLの場合と空文字の場合の両方を考慮しなければならない部分がありかなり混乱した…
LIKE演算子はあまり使わない(使う機会がない)
LIKE演算子はストアドでよく見かける（それこそ部分一致検索で）
- パターン文字にアンダースコアを使う場面はあまり見かけることが無いため忘れてしまっていた
BETWEENとINはよく使うが、ANYは一度も使ったことが無い気がする
BETWEEN演算子もあまり使わないが日付やIDの範囲指定とかで使うときはある
IN演算子はカラムの値が限られている（決まっている）時に使うことがある。例だと都道府県、業種など
ANY, ALL演算子は使ったことがない
- というか知らなかった
- いつもOR演算子で分けてた
「>」「<」と「=」の順番が分からなくなったときは頭の中で読み上げるようにしている
結構な頻度で「<>」を「!=」と書いてしまいがち
- これは確かにやってしまう
- Excelでも「<>」が使われている

複数の条件式を組み合わせる

AND, OR演算子も使うことは多い
データ抽出は条件が一つということはあまりないので多くの場合、ANDやORが含まれている
論理演算子の優先度に注意
- ()を使って明示的にしたほうがリスクが減りそう
AND、OR等の優先度を意識したことはあまりなく、括弧を使用して調整することが多い

主キーとその必要性

Railsだとテーブルを作成する際にIDの項目が自動的に作られる
- そのため、主キーよりも外部キー制約とかを意識することが多い
主キーが連番になっているデータはよく見るが、代替キー (サロゲートキー) といった呼び名はあまり意識したことがなかった。
人口キーや代替キーといった呼び方は知らなかった

まとめ

今回の読書会では文法に関する内容だったので業務での経験を交えながら意見交換を行えました。所属するグループによってはあまり使わない条件の演算子があるといった違いもありましたが、全員「UPDATEとDELETE」へはかなり注意をしているという部分では話が盛り上がりました。

次回は第4章「検索結果の加工」になります。次章で第1部が完了となります。

2023-05-09

「スッキリわかるSQL入門」読書会レポート vol.1

読書会

株式会社リゾーム技術部システム開発第4グループの平松です。「Linux標準教科書」読書会が終わり少し間が空きましたが今回も社内で有志を募り読書会を始めました。その内容をレポートにしていきたいと思います。

読書会の題材

題材として選んだのは、スッキリわかるSQL入門第3版ドリル256問付き！スッキリわかるシリーズです。

スッキリわかるSQL入門第3版ドリル256問付き！スッキリわかるシリーズ

作者:中山清喬,飯田理恵子
インプレス

Amazon

SQLの基礎からDB設計までを体系的に学べることができるかと思い、この本を選びました。

読書会の進め方

読書会の進め方はリゾームのテックブログで投稿している他の読書会記事と同じです。

読書会当日までに指定の章を事前に読んでおく
感想や疑問点をまとめて、Yammerにアウトプットする
当日、感想をそれぞれ発表して意見交換を行う

他の読書会記事はこちら

「現場で役立つシステム設計の原則」読書会レポート vol.1 - リゾームのテックブログ
 「入門監視」読書会レポート vol.1 - リゾームのテックブログ
 「Linux標準教科書」読書会レポート vol.1 - リゾームのテックブログ

1回目レポート

初回は第1章「はじめてのSQL」のレポートになります。参加者は7名でした。

それぞれの感想・意見交換

データベースとは

リゾームでは使用しているRDBMSとしてPostgreSQL, MySQL, SQLite, SQL Serverがある
担当製品で使用しているRDBMS以外は画面を見たことすらない
SQLが何の略かを書いていないのはなぜだろう？
- 現在、ISOの規格ではSQLを何かの略語として扱っていないらしい
列のことはカラムと呼ぶが行のことをロウって呼ぶ人は全然いない
どのDBMS製品でも基本は同じと書いてあるが、どの製品も色々と拡張しているイメージの方が強い

はじめてのSQL

SQLで何かするときはSELECTを使うことがほとんど
- INSERT, UPDATE, DELETEはあまり使ったことがない
テストデータの作成でINSERT, UPDATEを使用することがある
動作している環境に対して更新系のSQLを実行したことはない
- アプリケーションの制約の手の届かないところでデータを変更してしまうとデータの整合性が取れなくなってしまう場合があるため
PaaSのHerokuにはDataClipsというSQLを実行できる環境があるため、データ抽出する際はそこから操作している
テストチームで最初に渡されたクエリが「SELECT * FROM テーブル名 WHERE なんとかかんとか」だった
dokoQL はおもしろい。環境用意しなくてもSQLを試せるのはいい
- いつでも初期状態に戻せるので、安心してUPDATEやらDELETEやらできそう
テーブルやカラムの名前をつけるのは割と難しい
- テーブル名が英語の場合は複数形にするか単数形にするかという問題がある
- ローマ字表記の場合はヘボン式で統一するのも大事
SQLを書くとき、フォーマットどうするの？という問題もある
- 一般的なプログラミング言語だと自動フォーマットがかなり普及しているけど、SQLは人によって書き方がバラバラな印象
  - カンマの位置とかインデントとか
- 使ったことないけど、SQLFluffというlinterがあるみたい
初めて触った時はエクセルとか表計算ソフトみたいだなと感じた
同じDBMSでもバージョンで挙動が違う事が多いため検索などする際は注意
UPDATE、DELETE等で既存のレコードを変更する際には、WHERE句の指定が合っているかチェックするためにまずSELECTで対象を確認してから流すようにしている
業務を通してSQLを学んだので改めて書籍で体系だった知識を身につけたい
RailsだとActiveRecord経由でデータの操作をするため、直接SQLを書くことは少ない

まとめ

SQL自体の説明からSQLでどのようなことができるかなど基礎的な説明がほとんどでしたが、それぞれの担当製品で使用しているRDMBSについての話やどのような場面でSQLを使用することがあるかなど業務内容に沿った話を多くすることができたと思います。次章は「基本文法と4大命令」で、文法の内容に入っていきます。ここでも業務や経験と絡めた感想を共有していきたいと思います。