WITH句てんこもりのSQLをデバッグする - エムスリーテックブログ
巨大なSQLの出力が意図と違っていたり違っているかもしれないとき、どこから確認しようか頭を抱えてしまうことってありますよね。せめて多段階で作られているたくさんのCTE （WITH句）、これらが一つずつどんな表を出力しているのか簡単にのぞけたら手がかりもあるのだけれど⋯ 今回はそれをわりと現実的な手間でできるようにする小技です。エムスリーエンジニアリングループUnit1（製薬プロモーション）／Unit9（治験臨床研究支援）エンジニアの三浦[記事一覧 ]です。 魔法の一行 デバッグを実現する一行 We are hiring 魔法の一行 SQLの最後に -- */ という無意味なコメント行を付けておいてください。ひと目見て分かる通り、まったく無意味です。ところがこれがあるだけで、デバッグのときにこんなことができるようになります―― デバッグを実現する一行 次のようなCTEの大行列があるとします
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
リーダブルSQL[より良いSQLを書くためのシンプルで実践的なテクニック] - Qiita
はじめに 最近エンジニア界隈では「リーダブルコード」が話題なっていますね。 リーダブルコードでは、このような定理が紹介されています。 「コードは他の人が最短時間で理解できるように書かなければいけない。」 Dustin Boswell リーダブルコード P.3 より引用 皆さん、クソSQL1を読んだことがありますね？ クソSQLを書いたことがありますね？ 僕は、あります。 そこで、本記事ではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。 処理の流れの順に上から読めるようにする サブクエリを多用したSQLは複雑に絡み合った大きな複雑な塊になってしまいます。サブクエリを使ったSQLでは、処理の流れは上から下ではなく、ネストされた内側から始まります。しかも、必ず内側から読んでいけば理解できるかというとそうでもなくて、内側のクエリが外側のクエリの影響を受けていて、内側のクエリだけ
![リーダブルSQL[より良いSQLを書くためのシンプルで実践的なテクニック] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3419574e689b0c59c3db29dc4db2ac30ceb43c1b/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUUzJTgzJUFBJUUzJTgzJUJDJUUzJTgzJTgwJUUzJTgzJTk2JUUzJTgzJUFCU1FMJTVCJUUzJTgyJTg4JUUzJTgyJThBJUU4JTg5JUFGJUUzJTgxJTg0U1FMJUUzJTgyJTkyJUU2JTlCJUI4JUUzJTgxJThGJUUzJTgxJTlGJUUzJTgyJTgxJUUzJTgxJUFFJUUzJTgyJUI3JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFCJUUzJTgxJUE3JUU1JUFFJTlGJUU4JUI3JUI1JUU3JTlBJTg0JUUzJTgxJUFBJUUzJTgzJTg2JUUzJTgyJUFGJUUzJTgzJThCJUUzJTgzJTgzJUUzJTgyJUFGJTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz04ZmIzNTI3YjdmZjZkMGQ4ZDlkNDU5ZDE3YTgwOTE2ZA%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB6YWNrZXkyJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0xNWQ5ZDE5ODRhODljY2JhMGNmYWMzYmQxNmUxMzdkOA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-TSZB44Kv44Op44Km44OJ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25231E2121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D0e7b4ec63f049a7d65fb81ad515337b0)
社内SQL研修のために作った資料を公開します | 株式会社AI Shift
こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり
SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ
【PythonのORM】SQLAlchemyで基本的なSQLクエリまとめ - Qiita
SQLAlchemy1.2の基本的なクエリをまとめました！ python初心者以上向けの記事です。 改めて読み返してみると、直した方が良さそうな箇所や、この機能書かないんかいってのがあるので修正予定です。 記述内容 ORMについて、動かしてみるところまで、select, limit, orderby, distinct, join, leftjoin, in, insert, update, delete, union, unionAll, sql吐き出し, sqlを直接実行について また、flask-sqlalchemyでは実行を試していません。 SQLAlchemyとは pythonのORMモジュール。 session.query(User).all() このようにSQL操作ができる。 ORM SQLをクラスとして扱えるようにしたもの。 使用する理由は、 ・SQLインジェクション対策が
とりあえず使えそうな SQLAlchemy 入門（※ ORM機能は使いません） - エムスリーテックブログ
物資難の時代、化学者はカップ酒をビーカー代わりに使った・・・らしい（本文とは関係ありません） こんにちは、エムスリー・エンジニアリングG・基盤開発チーム小本です。 SQLAlchemyはPythonのSQLライブラリのデファクトスタンダードで、エムスリーでも使っていますが、意外と導入の障壁が高い。そこで、とりあえずSQLAlchemyを使い始めるのに必要な情報を調べました。 具体的には生の（文字列の）SELECT文を組み立て、クエリする方法を説明します。 なぜこの記事を書いたか SQLAlchemy の入門記事をググると、 SQLAlchemy は ORM です DBに接続しメタデータを取得します ベースモデルを継承し、モデルを定義し、テーブルと関連づけます といった、 「重い」使い方の記事ばかりがヒットします。そのせいか、 「SQLAlchemyは難しい」 「SQLAlchemyはORM
SQLスタイルガイド · SQL style guide by Simon Holywell
概要 全般 推奨 非推奨 命名規則 通則 表 列 別名、相関名 ストアド・プロシージャ 統一的接尾辞 問合せ文 予約語 空白類 インデント 望ましい形式 Create文 データ型の選択 デフォルト値の指定 制約とキー 非推奨設計 付録 予約語リファレンス SQLスタイルガイド（日本語訳） 日本語訳について 日本語訳は誤訳や原文の最新版に追随していない恐れがあります。誤訳や改善点があれば、GitHubのissueまたはpull requestを使用するか、Twitterでお知らせください。 翻訳: 久利史之 @nkuritw 概要 このガイドラインは利用の他、forkしたり、自分自身のものに改変したりすることができます。ここで大事なのはスタイルを選択しそれを踏襲することです。変更の提案やバグの修正にはGitHubのissueまたはpull requestを使用してください。 このガイドライン
地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
ディレクターがSQLを使えてよかった話 - クックパッド開発者ブログ
こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。 ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった！と感じているSQLについてお話ししたいと思います。 いきなりですが、SQLが使えてよかった点をまとめると以下です。 よかったこと 数値抽出から分析まで自己完結 エンジニアとのコミュニケーションがスムーズに 仕事が増えていそうで実は効率アップ 周囲の知的好奇心を刺激 それぞれ具体例を交えてお話します。 数値抽出から分析まで自己完結 事例１：ログ構造を理解でき後の仕事がスムーズに 昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1。 アプリのリリースはタイミングが決められ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sqls-server/sqls: SQL language server written in Go.
MySQLアンチパターン