はじめに こんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。 今日はSQLについてです。 弊社に入社してから毎日のようにSQLのクエリを書いてきました。 クエリを書き始めてからもう3年が経とうとしています。 日々クエリを書きながら少しずつ自分のスタイルが出来上がってきているのを日々実感しています。 僕は 正確で 読みやすく 再利用しやすいクエリを 高速に 生み出すための工夫を重ねてきました。 結果的にテスト駆動開発ぽいスタイルが生まれたので今日は紹介してみようと思います。 似たような記事がないので少しドキドキですが温かい気持ちで読んでもらえると嬉しいです。 対象読者 対象読者は、分析のためにクエリを書いている人とします。 プロダクトに乗せるクエリというより、ビジネス的になにか示唆を得たいときにクエリを書く人を想定します。 痛み
Google Cloudのデータエンジニアをしています、はんざわです。 今回はSQLのリンターであるSQLFluffを触りながら理解を深めたいと思います。 検証環境 macOS： 13.3.1 Python： 3.9.5 SQLFluffとは SQLFluffとは、SQLのフォーマットを自動で問題点の指摘や修正をしてくれるオープンソースサービスです。 さっそくインストールして使ってみたいと思います。 インストール SQLFluffをインストールするにはPython3が必要です。 $ pip3 install sqlfluff 正常にインストールできているか確認します。 $ sqlfluff version 2.0.7 インストールが完了しました。実際にクエリを用意し、使ってみたいと思います。 さっそく使ってみる sqlfluffには大きくlintとfixの2つの機能があります。 まずはli
こんにちは、Wantedlyでデータサイエンティストをしている樋口です! 自分は過去、分析のためにSQLを書いているとき、以下のようなミスをしていました。 メール開封率を集計したら何故か100%を超えてしまった。でもどこが原因かがわからない メール開封率を集計したのち、クリック率も追加で依頼を受けたが、再利用できるクエリになっておらず、一から書き直した クエリのレビューを依頼したら、複雑すぎると言われてしまった こういった経験がある方は自分以外にもいるのではないでしょうか...! SQLは非常に自由度が高く便利である反面、書き方が個人に委ねられ、複雑・難解になりやすいと感じています。 そこで本記事では、自分が実務で学んだ、読みやすく、再利用しやすいSQLクエリの書くコツを紹介したいと思います。個人の経験によるものなので、より良い書き方・考え方もあるかもしれないです。ご了承ください🙏 読み
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ
trdsqlというコマンドラインツールを作りました。 Goで作ってます。 githubの trdsqlからダウンロード出来ます。 またLinux/Windows/macOSのバイナリもあります。 以下は、古くなっている内容もいくつかあります。 最新版に対応した、より詳細な内容は trdsql 目次 | Noboru Saito's page を参照して下さい。 これは何？ 簡単に言えばCSV(TSV含む)やLTSVに対してSQLを実行できるツールです。 同様のツールが q や textql 等いくつかあります。 trdsqlはPostgreSQLドライバとMySQLドライバを含んでいて実際にDBに接続することでSQLite以上の機能を使用できるようにしています。 PostgreSQLやMySQLの構文が使えるだけではなく、CSVファイルと実テーブルでJOINしたり、CSVファイルからテーブ
日本国内のウェブサイトにおける SQL インジェクションの脆弱性が、国内外から JPCERT/CC に複数報告されています。 日本国内のウェブサイトにおける SQL インジェクションの脆弱性が、国内外から JPCERT/CC に複数報告されています。 オー プンソースの SQL インジェクション脆弱性診断ツール sqlmap を使用して、日本国内のウェブサイトで動作するウェブアプリケーションの脆弱性を検出しようとする海外からのアクセスが発生しています。こうしたアクセスは組織規模の大小によらず、中小企業や個人のウェブサイトに対しても行われています。SQL インジェクションの脆弱性が存在するウェブサイトでは、ユーザや開発者の意図しない SQL 文が実行され、様々な影響を受ける可能性があります。 sqlmap は、おもに次の 5つの手法を使用します。 Boolean-based blind WH
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 海外の xkcd というサイトにこんな4コマ漫画が掲載されています。 英語ですが、じっくり読んでみてください。 きっと「あー、なるほど（苦笑）」と思うはずです。 えっ、わからない？？ じゃあ、日本語訳を載せましょう。 もしもし、小学校の者ですが。今ちょっとコンピュータのトラブルが起きてまして。 あら大変、うちの息子が何か壊しましたか？ / まあ、そんな感じですが・・・。 お母さん、あなたは本当に息子さんに "Robert'); DROP TABLE Students; --" という名前を付けたんですか？ / ええ、そうですよ。みんな「
WHERE条件をつけまくる UPDATE user SET age = 35 WHERE id = 1 AND name = 'Songmu' AND age = 34 idだけで絞れるけど name も付けてレビュワーフレンドリー 変更前の値も条件に含める 34 -> 35になることがわかる 間違えていた時も戻せる ユーザー操作とのコンフリクトを検知 万が一履歴から誤爆しても更新されない(可能性が高い) SETとWHEREを一行にまとめてるのは変なところで小指が滑るのが怖いため WHERE条件応用編 UPDATE user SET weapon_id = (SELECT id FROM weapon WHERE id = 100 AND name = '村正') WHERE id = 1 AND name = 'Songmu' AND weapon_id = (SELECT id FRO
オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ
メールアドレスの「ルール」に関する話題が盛り上がっていますね。 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を 「メールアドレスのルール」なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、「空前のメールアドレスのルールブーム(?)」に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
Index of /SQL NameLast modifiedSizeDescription Parent Directory - sql-2003-2-railroad-..>2024-02-04 17:51 5.3M sql-2003-2.ebnf 2024-02-04 17:51 172K sql-2003-2.ebnf.readme 2024-02-04 17:51 757 sql-2016-railroad-di..>2024-02-04 17:51 6.8M sql-2016.ebnf 2024-02-04 17:51 214K sql-2016.ebnf.readme 2024-02-04 17:51 663
SELECT文を考える時、何となくjoinやgroup byとか使ってませんか？もしくはメインとなるテーブルを意識していますか？ SELECT文は非常に便利なので気づかないのですが裏で実行されている事は（非常に簡単に言うと） ・縦＊横の二次元の表を付きあわせ、新たな縦＊横の二次元の表を作成 しているだけなのです。 その際に、一行の粒度が変わる事に注意が必要です。多重度が大きい側にjoinすると、自ずと一行の粒度が変わってしまう（行が増えてしまう）為、初心者のうちは自分が何をしているのか分からなくなります。 例えば次のER図があり、 最終的に次のような表が欲しい場合、どういうSQLを書きますか？ 私は概ね次のステップでSELECT文を考えます。 ・最終アウトプットの一行の粒度を確認する。 この場合注文明細の行数が最終アウトプットの行数と同じ ・その粒度にあったテーブルをメインの表にする。 f
PostgreSQL Advent Calendar 12/1 ついにPostgreSQL Advent Calendarが始まりました。一日目は@choplinからお届けします。 SQLはプログラミング言語である みなさんSQLは好きですよね。 ところでSQLはRDBの操作を行うための言語だと一般的には考えられています。SQL - WikipediaによるとSQLはその為に作られた言語だそうですし、その使い方でとっても素晴らしい働きをしてくれます。 しかし、DBを用いずとも、SQL単体で様々な計算が可能だということはあまり知られていないようです。本エントリではその知られざる実力の一端をご紹介いたします。 SQLで素因数分解を行う ご存知かとは思いますが、素因数分解とはある正の整数を素数の積の形で表すことです。 ぱっと見では中々SQLで解きにくい問題ではないでしょうか？ Project E
SQLインジェクションについて書くときに以下のメッセージを必ず含めて欲しいです。 単にプリペアドステートメントを使え 絶対に文字列結合でSQLを構築しようとしてはいけない IPAの「安全なSQLの呼び出し方」を読むこと なんでこんなことを書くかというと、同僚が献本されてた「プロになるためのWeb技術入門」なる本のSQLインジェクションの項で、SQLインジェクションの対策として以下のように書いてあったからです*1。 a) 値をバリデーションする b) プリペアドステートメントを使う ダメです。間違っています。単に間違っているだけでなく救いがたく間違っています。正しいSQLインジェクション対策はこう書くべきです。 単にプリペアドステートメントを使え 文字列結合でSQLを構築するな イケてない本を書く人はなんで値のバリデーションをプリペアドステートメントよりも先に書くんですか？値のバリデーション
第四企画 坂井 潔 ここではPHPでSQLインジェクション対策としてエスケープ・クォート処理を行うケースを説明します。なおSQLインジェクションの簡単な説明や、プレースホルダを用いてより効果的な対策を行うケースに関してはプレースホルダ編を参照してください。 エスケープとは？ それではエスケープ処理とはなんでしょうか？ 分かりやすいケースとして、文字列を扱う場合を説明します。 例えば「名前がO'Reillyの行をテーブルusersから取得する」あるいは「テーブルusersに、名前はO'Reilly、メールアドレスはo'reilly@example.comとo'reilly_mobile@example.netの２つを改行で繋げたデータを、行として挿入する」と言ったSQLをつくると、この命令文全体が１つ文字列になります。その命令文としての文字列の中に、値としての文字列を埋め込む場合には、それが
こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん！ addslashes本当にマジでチョームカつくんですけどぉぉお〜！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜！ サテ技本に載ってたからずっとaddslashes使ってるんですけどぉ〜！ 日本語が化けるんですぅ〜！ ぷんぷくり〜ん（怒）」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か
オラクルエンジニア通信というサイトのOracle データベースの監視およびパフォーマンス・チューニングという技術資料の一覧がちょっと整理されていないのが残念だなと思いながらどんな資料があるかチェックしていたら、「えっ、こんな資料を公開してもいいの？」というぐらいの詳しいというかわかりやすいというか高いレベルの資料が見つかった。 SQLチューニングと銘打っているが、カバーしている範囲は幅広くなぜそう考えるのかの理由やアプローチの仕方があるのが素晴らしい。 【セミナー動画/資料】オラクルコンサルタントが語る SQLチューニングの真髄 解決編 Part1＆2 PDF資料：http://www.oracle.com/technetwork/jp/content/sql-254794-ja.pdf 目的とゴール SQLパフォーマンス問題の理由と原因 / SQLパフォーマンス問題の定義、SQLパフォー
BNF Grammar for ISO/IEC 9075:1999 - Database Language SQL (SQL-99) Cross-Reference: rules Cross-Reference: keywords Derived from file sql-99.bnf version 2.8 dated 2004/07/26 18:00:06 Generated on 2005-07-13 18:32:52+00:00 by file bnf2html.pl version 3.7 dated 2005/07/13 18:32:35 Using Appendix G of "SQL:1999 Understanding Relational Language Components" by J Melton and A R Simon (Morgan Kaufmann
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く