t-wadaさんに聞く！『SQLアンチパターン第2版』 全27章まとめて紹介 - Findy Media
本記事では、2025年7月28日に開催され、約1,500名が申し込んだイベント「t-wadaさんに聞く！SQLアンチパターン第2版 - 全27章まとめて紹介！」の内容をお届けします。イベントでは、書籍『SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策』の出版を記念して、監訳者であるt-wada（和田卓人）さんをお招きし、本書の魅力についてご講演いただきました。ぜひ本編のアーカイブ動画とあわせてご覧ください。 t-wada： 本日は『SQLアンチパターン 第2版』という本についてお話しします。第2版も私が監訳しています。本日の講演では、先日の「Developers Summit 2025 Summer」で講演した内容をより厚く、各章の内容に踏み込んで説明します。 はじめに時は2025年、世界はバイブコーディングの炎に包まれました。 AIと一緒にコードを書く
MySQLのロック継承が引き起こしたsupremumロックによるDB障害事例 - freee Developers Hub
こんにちは、DBREの周東（X: @dev_kngnr）です。 DBRE では、freee の全プロダクトが利用するデータストア層の信頼性向上をミッションとしています。その活動の一環としてDB障害の原因の調査や、再発防止策の検討を行っています。この記事では、freee のとあるサービスで実際に起こった DB 障害と、その引き金となった MySQL のロック継承の仕組みについて紹介します。 概要 今回紹介するDB障害では、Aurora MySQL への接続失敗が頻発し、最終的には Web を開くこともできない状態にまで発展しました。原因を調査したところ、ROLLBACK TO SAVEPOINTによって引き起こされるロック継承が予期しないロックを発生させることが判明しました。この挙動とロングトランザクションが組み合わさることによって、たった一行のレコードロックのロールバックが Web サービ
WITH句てんこもりのSQLをデバッグする - エムスリーテックブログ
巨大なSQLの出力が意図と違っていたり違っているかもしれないとき、どこから確認しようか頭を抱えてしまうことってありますよね。せめて多段階で作られているたくさんのCTE （WITH句）、これらが一つずつどんな表を出力しているのか簡単にのぞけたら手がかりもあるのだけれど⋯ 今回はそれをわりと現実的な手間でできるようにする小技です。エムスリーエンジニアリングループUnit1（製薬プロモーション）／Unit9（治験臨床研究支援）エンジニアの三浦[記事一覧 ]です。 魔法の一行 デバッグを実現する一行 We are hiring 魔法の一行 SQLの最後に -- */ という無意味なコメント行を付けておいてください。ひと目見て分かる通り、まったく無意味です。ところがこれがあるだけで、デバッグのときにこんなことができるようになります―― デバッグを実現する一行 次のようなCTEの大行列があるとします
DSLやめてSQLでいいんじゃない？
ORMはCUD処理は得意ですが、R（SELECT）処理は苦手です。 DSLのゴールはSQLへの翻訳であるのに、答え（SQL）を知っていても、わざわざ逆翻訳（DSL）しなければならない。 その上、各ORMライブラリごとにDSLの文法は異なり、SQL以上に方言だらけの世界です。 そこで改めて考えたい。なぜSQLを使わないのですか？ SQLを忌避する理由 私が想像する理由は大きく5つあります。 SQLインジェクションが怖い 汎用性が低い 静的解析やコンパイルチェックが効かない エンティティモデルへのマッピングが面倒 長文の保守性が悪い これは今も本当に問題なのでしょうか？ SQLの解析、加工が出来れば解決しませんか？ 問：SQLインジェクションが怖い メンバーのスキルによってはちょっと怖い。 SQLを文字列連結するのは危険。 答：SQLと検索条件を合成できれば心配ない SQLを解析、加工できれば
人間のためのリーダブルSQL
読みにくいと感じた SQL の例を作るにあたり、私自身が目にしてきた SQL を例として出しますが特定の個人を非難したいものではないことを最初に書かせてください。 人類全体でより良い SQL を書いてより良いデータ活用をしていこうぜ！と言う趣旨の記事になります。 これは何？ 私 tenajima が分析用の SQL を書くときに意識していることになります 以前書いた「データ基盤のためのリーダブル SQL」はデータ基盤開発者向けに書きましたが、今回はデータ基盤や dbt のコードではなく一般的な SQL を書く人向けのリーダブル SQL という立ち位置で書きたいと思います 当初は「分析者のためのリーダブル SQL」として書こうと思いましたが、エンジニアの人も bizdev の人も人事の人も、SQL を書くなら誰にでも意識してほしいなと思い、「分析者」をとっぱらいました(結果人間なのかというツ
データ分析で用いるSQLクエリの設計方法
STEP2. アウトプットを実現するために必要なデータソースを書き出す アウトプットの整理ができたら、今度はインプットとなるデータソースの整理を行いましょう。 必要なデータソースは要件から読み解くことができます。 今回は「10代のユーザーの月間視聴数（性別 / 動画カテゴリごと）の推移をグラフで見たい」という要件です。 ここから、この分析に必要なエンティティ（実体）とその属性、集計値を抽出しましょう。 エンティティと属性 ユーザー 性別 年代 動画 カテゴリ 集計値 視聴数 これらのデータを管理するテーブルを、調査やヒアリングを実施して探します。 今回は以下のテーブルを使用することとします。 user：ユーザー登録に必須な入力項目を管理するテーブル user_profile：ユーザーが登録後に設定できる任意の入力項目を管理するテーブル video：ユーザーが投稿した動画を管理するテーブル
ORDER BYとLIMIT, OFFSETの組み合わせには注意しよう｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
こんにちは、下條です。今日はSQLの軽い (しかし重要な) 話題について書いてみようと思います。 まずは以下の通りユニークでない col カラムを含む test テーブルを作成し、データを投入するSQLをご覧ください。 (MySQLでの例です。) create table test(id INT, col INT); insert into test values(1,1); insert into test values(2,1); insert into test values(10,1); insert into test values(3,1); そして、以下の2つのSQLを実行した場合、結果はどうなるでしょうか？ここで何が言いたいかが分かる方はこの先は読まなくてかまいません。 select * from test order by col limit 2 offset 0; se
Don't use DISTINCT as a "join-fixer"
https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/dont-use-distinct-as-a-join-fixer/ I’ve quietly resolved performance issues by re-writing slow queries to avoid DISTINCT. Often, the DISTINCT is there only to serve as a “join-fixer,” and I can explain what that means using an example. Let’s say we have the following grossly simplified schema, representing custo
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
ワンランク上のSQLを書くためのポイント3つ - Qiita
この記事はNuco Advent Calendar 2022の17日目の記事です。 ワンランク上のSQLとは？ 1年近く、データ分析に関わる業務に携わっってきた中で、良いSQL、いまいちなSQLをいろいろ見てきました。 自分が書くSQLも、最初の頃は目も当てられないSQLも書いてきました。そんな中で、こんなことを意識していくと、より良いSQLになるのでは？というポイントをまとめていきます。 とりあえずSQLの文法は一通り勉強して、取得したいデータをとってくるSQLをかけるようになったぞ。という人に向けたものなので、本当に基礎的な文法は解説していません。 ワンランク上のSQLを書くためのポイントは、 ・読みやすい ・再利用しやすい ・処理が早い の３つを押さえられているかどうかだと感じています。 可読性が高いメリット 間違いにくくなる/デバックが容易になる エラーが出てくれれば間違っているこ
社内SQL研修のために作った資料を公開します | 株式会社AI Shift
こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で
非エンジニアが気づいたらSQL書けるようになった話｜Toshi_Day1｜note
今年の夏の時点ではSQL？なにそれ美味しいの？状態だったけど、雑にサブクエリやCASE、UNION等をある程度自由に使えるようになってた、と昨日気づいた。 個人的には思っているのは、SQL自体はエンジニア、デザイナー、ビジネス、マーケター、プロダクトマネージャーなど、エンジニア/非エンジニアなどの職種に関わらずプロダクトに関わる全ての人間が最低限のSQLを身に付けるのがいいのではないかということ。 今回はタイトルにあるように、非エンジニアの自分がSQL書けるようになるまでの軌跡ついて書こうと思う。夏頃まで専属メンバーが自分1人だったBASEの金融事業、子会社BASE BANKの立ち上げ責任者をやる中で、ふとささやかな成長を実感することができた高揚感とノリでそのまま書くのでどうか生暖かく見守ってほしい。 *BASEを退職してCrezitを創業しました！ SQLの学習を始めてから、社内で非エン
非エンジニアにSQLを布教して社内に起きた明るい変化 - てくすた
はじめまして。エンジニアの id:cheezenaan と申します。いよいよ夏本番、ビールがおいしい季節になりましたね。 今回は、5月から取り組んできた「非エンジニア向けSQLの書き方勉強会」を通じて社内に起きた変化について、軽く話をさせてもらえればと思います。 いきさつ ピクスタはここ数年でエンジニアや営業、マーケティング等さまざまな職種のメンバーを迎え入れてきました。去年からピクスタにジョインしたメンバーが社内の約4割を占めるほどです。また人員拡大と並行して、様々な施策にも取り組んできました。最近ですと「少しだけ定期的に画像を使いたい」ユーザー向けに新設した少額定額プランのリリースが記憶に新しいのではないでしょうか。 このような施策を実施する前の仮説立案や実施後の効果測定、また定例のミーティングで使用するKPI等、データ(数値)とにらめっこする場面は、みなさんの会社でも多いことかと思い
【レポート】社内のSQLを書ける人数が3倍になりました | 株式会社スペースマーケット
エンジニア兼PMの柿木です。 今年1月から2月にかけて、スペースマーケットでは、社内のデータ分析力を底上げすべく、社内でSQLワーキンググループを作り、勉強会を行いました。 非エンジニアでSQLを書ける人は3-4名いたのですが、今回の勉強会を通して、おそらく10名以上がSQLを書けるようになりました。 今回はその勉強会の内容をご紹介したいと思います。 なぜSQLの勉強会を行ったか今回の勉強会は私が企画したのですが、勉強会を行おうと思った理由は2つありました。 1つめは、スペースマーケットをデータ分析に強いチームにしたかったためです。ビジネス開発、マーケティング、カスタマーサクセス、どのチームでも、データ分析は仮説を立てる上でとても大切です。そして、その仮説は対象のデータが正しいことが前提となります。 データや情報はいかに一次情報にアクセスできるかが重要です。エンジニアの技術情報などもブログ
カンム社員全員でSQL勉強会をやっている話
株式会社カンム では、毎週火曜日17:00 - 18:00の時間をとって全員参加のSQL講座をやっている。2018/4から続けているのでそろそろ10ヶ月程経過するのでどのように継続してきたか、どのような効果があったか等を書く。 前提 カンムは バンドルカード というサービスを提供しており、2019/01末時点で正社員13名のまだ小さなチーム。このSQL講座開始当時、SQLを業務で書ける人員は社長を含め5名くらいだった。また、redash は本番/検証ともに整備されており、以前は主要KPIのダッシュボードは社長の 8maki と自分が作ってた。 バンドルカード自体を作ってる様子はこちら。 バンドルカードを作ってる by achiku バンドルカードができるまで by ideyuta 発端 自分がソフトウェアエンジニアからマーケティング側に移籍した話は 前回書いた。長いのでまとめると、今まで5
SQLをはじめよう - 初心者でもわかる、構文とデータ取得の基本 - エンジニアHub｜Webエンジニアのキャリアを考える！
SQLをはじめよう - 初心者でもわかる、構文とデータ取得の基本 リレーショナルデータベース管理システム（RDBMS）において、データの操作や定義を行うためのデータベース言語であるSQL。“データ”の重要性が謳われるようになった昨今において、この言語はより重要性を増しています。本稿では日本MySQLユーザ会の副代表であり、データベースを中心とした業務システムの設計・コンサルティングを手掛ける坂井恵さんが、「SQLを学びはじめたばかりの若手IT技術者」や「社内のデータを利用したい非IT技術者」に向けて、SQLによるデータ操作の基礎を解説します。 企業活動において、近年ますます、蓄積されたデータの活用が重要になっています。自社の持つ大量のデータの中から必要なデータを抽出・集計するという操作は、以前はITエンジニアが用意した画面を通して限定的にのみ行うことができるのが一般的でした。 しかし最近は
SQLスタイルガイド · SQL style guide by Simon Holywell
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド（日本語訳） 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
Sequel Proを超えるGUIツールが出てきたぞ
悲報 2019年6月26日現在、TeamSQLのサポートがなくなってしまったようでダウンロードできなくなくなりました。。 TeamSQL has retired and is not available for download anymore. 今までSequel Proを重宝してきましたが、それを超えるGUIツールが出てきました。 その名も、TeamSQL 現状サポートしているものだけでもかなり豊富 今後、elasticやmongoDBにも対応されるようです。 機能 クエリ保存 履歴保持 ファイル出力 抽出した結果をボタン１つでcsvやjson形式に保存可能。 共有 データをエクスポートしなくても共有が可能。 グループの作成が可能なため、特定のユーザー同士で簡単に共有ができるとこがメリット。 可視化 様々なチャートでクエリの可視化が可能。 そのままイメージとして保存も可能。 テーマ選択
MySQLで月別、日別、時間、曜日別にレコード数を集計する方法 - おおらかにいこう
会員登録数などを調べるときに、月別、日別、時間、曜日別の登録者数を調べたいってよくありますよね。 そこで今回は、MySQLでdatetime型のカラム(今回は「regist_time」としています)を使って月毎、日毎、時間、曜日毎にレコード数を集計をするSQLの紹介です。 ■月毎 SELECT DATE_FORMAT(regist_time, '%Y-%m') as regist_time, COUNT(*) as count FROM users GROUP BY DATE_FORMAT(regist_time, '%Y%m'); ■日毎 SELECT DATE_FORMAT(regist_time, '%Y-%m-%d') as regist_time, COUNT(*) as count FROM users GROUP BY DATE_FORMAT(regist_time, '%Y
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OFFSETを使わない高速なページネーションの実現 - Qiita
