株式会社リゾーム 技術部 システム開発 第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部が完了となります。
