保守性と生産性を両立する分析用SQL構造化の4原則 〜 構造化プログラミングの考え方をSQLに適用する
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!広告のデータマーケティングソリューション（以下、DMS）を開発しているデータアナリストの薄田です。 みなさんは、中間テーブル同士が複雑に絡み合い変更しようにも影響範囲を推定できず、手がつけられない分析パイプラインの保守で苦労された経験はないでしょうか？ 私のチームでは数千行におよぶ分析用SQLをリファクタリングして、保守性と生産性を両立する分析パイプラインに生まれ変わらせることができました。 この記事ではリファクタリングを通して確立した、分析用SQLを構造化するための4原則を紹介します。4原則を意識しながらSQLを書くことで、高凝集・疎結合な分析パイプラインを作ることができます。 この記事では凝集度と結合度
データベース言語SQL 初心者用データベース入門
マンガでわかるデータベース 特定ベンダーの製品によらないデータベースの概念を、マンガでやさしく解説。果物の輸出に追われる王国の姫が、データベースによる解決策を1つ1つ学んでいくというストーリーをとおして、データベースの基本的な概念を身につけることができる。情報処理技術者試験対策にも役立つ練習問題付き。 SQLの絵本―データベースがみるみるわかる9つの扉 データベースを思いどおりに動かそう！見る・ためす・わかる！入門書 SQLはデータベースを操作するために覚えるべき技術ですが、難しくてなかなかものにできないという人も多いのではないでしょうか。本書は、かわいいイラストで解説しているので、直感的にイメージをとらえることができ、理解も進みます。さあ、扉を開いて、SQLの達人への道を進みましょう！
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル
TypeScriptで世界一型安全な型レベルSQL Interpreterを作っている話
こんにちは。DevOps芸人と化して久しいAndyです。 2020年の秋にTypeScript 4.1へTemplate Literal Typesが導入され、そのインパクトに俄かに一部の界隈がザワついたのは記憶に新しいかと思います。 今回は型プログラミングの可能性を大いに押し広げたTemplate Literal Typesを用いてSQL文を型レベルで解析し、その実行結果を型情報として導出するためのsqlptureというライブラリを作ったので紹介します。 Embedded content: https://github.com/andoshin11/sqlpture SQLの実行/検証対象はPostgreSQL v13です。 tl;dr SQL文を型レベルで解析・評価して返り値型を取得できるmini interpreterを作ったよ 型レベルのSQL validatorも作ってるよ 実際
INNER JOIN ON vs WHERE clause
For simplicity, assume all relevant fields are NOT NULL. You can do: SELECT table1.this, table2.that, table2.somethingelse FROM table1, table2 WHERE table1.foreignkey = table2.primarykey AND (some other conditions) Or else: SELECT table1.this, table2.that, table2.somethingelse FROM table1 INNER JOIN table2 ON table1.foreignkey = table2.primarykey WHERE (some other conditions) Do these two work on
「スパゲッティクエリ」の解決策は断じて「ぐるぐるクエリ」ではない!! : i am BEST
2013年06月11日01:35 カテゴリSQLデータベース 「スパゲッティクエリ」の解決策は断じて「ぐるぐるクエリ」ではない!! 『SQL アンチパターン』という本に「スパゲッティクエリ」というアンチパターンが載っています。（17章） 名前だけでなんとなくわかった気になるアンチパターンなのですが、実はその「わかった気」は違っているのでは?! というのが今回のお話です。 「マッチョなクエリ」 以前、『SQL アンチパターン』を題材にしたセミナーに出たことがありました。 その時、参加者がこのアンチパターンについて「マッチョなクエリはよくない」とか「複雑なSQL はよくない」といった感想をもらしているのを聞きました。 そのまま続けていろいろ聞いていると、どうも「単純な SELECT などをプログラムのループでまわして結果を取得した方が、SQL のいろんな機能を使うよりいい」というようにこの「ス
SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? : i am BEST
2014年09月03日02:46 カテゴリSQLデータベース SQL での”再利用””部品化”はユーザー定義関数ではなくビューで実現できる!? 最近のたいていのデータベース製品では、ユーザー定義関数（UDF）という機能が使えるようになっています。Oracle では”ストアド・ファンクション”と呼ばれているものですね。 よく”処理の再利用”とか”処理の部品化”といった用途に使われていますが、パフォーマンスの問題が起こってしまうケースがままあるんですね。 ”集合”を原理とするリレーショナル・データベースの SQL 処理に対して”手続き指向”の発想で立ち向かってしまい、いろんな問題を起こしてしまうことがよくあります。これもそうした例のひとつと言っていいでしょう。 では、”集合指向”での再利用・部品化とはどのように行なうものなのでしょうか?? その答えは、「ビューの利用」なんです。 ユーザー定義関
SQLの部品化について
非実在naka aki @naka_aki_spl 再掲。SQLは、「完結したクエリ(つまりビュー)」だけじゃ部品化の粒度として大きすぎる。条件とかもを部品(名前付き部品も含む)化したい。個人的に今一番気がかりなのは「結合条件」の「部品」化。 2014-01-30 20:45:44 非実在naka aki @naka_aki_spl ただ、部品化といっても、特に結合条件なんてものは「任意のテーブル/サブクエリ」と好き放題に組み合わせれるハズが無い。使える組み合わせは強く拘束されるはず。、、、これって「型」じゃないのか？ 2014-01-30 20:48:58 非実在naka aki @naka_aki_spl ある検索条件(ANDとかで複数合体するのも当然アリ)が「どのテーブル(やクエリ)を指すことができるか」は、「型」だよな。a.b=c.dなんてな条件は、テーブル粒度でいえば「aからcを
非エンジニアにSQLを布教して社内に起きた明るい変化 - てくすた
はじめまして。エンジニアの id:cheezenaan と申します。いよいよ夏本番、ビールがおいしい季節になりましたね。 今回は、5月から取り組んできた「非エンジニア向けSQLの書き方勉強会」を通じて社内に起きた変化について、軽く話をさせてもらえればと思います。 いきさつ ピクスタはここ数年でエンジニアや営業、マーケティング等さまざまな職種のメンバーを迎え入れてきました。去年からピクスタにジョインしたメンバーが社内の約4割を占めるほどです。また人員拡大と並行して、様々な施策にも取り組んできました。最近ですと「少しだけ定期的に画像を使いたい」ユーザー向けに新設した少額定額プランのリリースが記憶に新しいのではないでしょうか。 このような施策を実施する前の仮説立案や実施後の効果測定、また定例のミーティングで使用するKPI等、データ(数値)とにらめっこする場面は、みなさんの会社でも多いことかと思い
PL/pgSQLデバッガを使ってみよう
PostgreSQLのPL/pgSQLはプログラムロジックをデータベース側で実行させる非常に強力な機能です。今回は、PL/pgSQLとそのデバッガについてご紹介します。 ■PostgreSQLの「PL/pgSQL」とは PostgreSQLのPL/pgSQLは、データベース側にプログラムのロジックを埋め込むための仕組みで、通常のSQL（DDL、DML等）に制御のための構文が追加されてたような言語仕様になっています。 PL/pgSQL - SQL手続き言語 http://www.postgresql.jp/document/9.0/html/plpgsql.html 私自身、このPL/pgSQLをよく使うのですが、PL/pgSQLのひとつの難点は、ロジックが複雑になってくるとデバッグが難しい、ということでした。 そのため、伝統的なデバッグの方法、いわゆる「printfデバッグ」に頼ることにな
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
ドメインロジックとSQL：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 旧聞ですみません。 ドメインロジックとSQLというのは、Martin Fowler氏というアジャイル・XPの提唱者の1人が書いたブログ一説です。そこから、SQLを考えてみましょう。 ■Martin Fowler氏のブログについて この記事はMartin Fowler氏のブログを読んで頂かないと理解できない内容かもしれません。 Rubyをやったことのない人はちょっと戸惑うかも知れないが、ぜひ、先ずはMartin Fowler氏のブログからがんばって読んでください。 今回、Rubyを使ってサンプルを作っている。いつもはJavaやC#（アプリケーション開発者が読めるC言語ベースのプログラミング言語）を使うのだが、まあいいややっちゃえーって思ってやってみた。Rubyを選
SQLに依存することの危険性 ー 単体DBサーバでは終わらない時代の考え方 | 独り言v6
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
「相関サブクエリ」とは何かを理解して，複雑なSQLでも読めるようになろう - 主に言語とシステム開発に関して
SQLの「相関サブクエリ」がわかれば・・・ 巨大なSQLが，迷わずに読めるようになる。 「関数」のような，便利なサブクエリを書けるようになる。 以下では， 「相関サブクエリ」とは何か？ 普通のサブクエリ（非相関サブクエリ）やJOIN操作とは何が違うのか？ 多重にネストされた，巨大なSQLの読み方は？ という点を論じる。 サンプルデータ，および全体の方針 （１）サブクエリ無しでJOIN （２）INで非相関サブクエリ （２）の補足：サブクエリを「関数」と考えてみよう （３）EXISTSで相関サブクエリ 他のサンプル 巨大SQLの読み方 サンプルデータ，および全体の方針 まず，相関サブクエリの説明のために，以下のようなテーブルを例として取り上げる。 table1が，普通のデータ table2が，マスタデータ（ホワイトリスト） 「マスタに一致しないレコードをはじく」という操作をしたい。 方法は３パ
今夜こそわかる安全なSQLの呼び出し方 ～ 高木浩光氏に聞いてみた
「安全なSQLの呼び出し方」というSQLのセキュリティに焦点を当てたドキュメントが、2010年3月にIPA（独立行政法人情報処理推進機構）から公開された。 これは2006年1月から提供されている、Webサイト開発者や運営者向けのセキュアWebサイト構築のための資料「安全なウェブサイトの作り方」の別冊として書かれたものである。「安全なウェブサイトの作り方」が92ページなのに対して、SQLインジェクションについてだけで40ページもの分量がある。なぜこんなに分厚いのだろうか。 このドキュメント作成に協力したという、独立行政法人産業技術総合研究所 情報セキュリティ研究センターの高木浩光氏にお話を伺うことができた。高木氏は個人ブログ「高木浩光＠自宅の日記」で、セキュリティ関連の問題を追求する論客としても知られている。筆者も以前、この連載の「今夜わかるSQLインジェクション対策」の回（2006年11月
変数に型のない言語におけるSQLインジェクション対策に対する考察(4): SQLの「暗黙の型変換」で実行速度が遅くなるのはどのような場合か - 徳丸浩の日記(2007-06-14)
_SQLの「暗黙の型変換」で実行速度が遅くなるのはどのような場合か 数値リテラルをシングルクォートで囲むことの是非にて、「変数に型のない言語」(Perl、PHP、Rubyなど)で数値項目に対するSQLインジェクション対策について検討した。その際に、数値リテラルを文字列リテラルとしてシングルクォートで囲む(中の値はエスケープする)という方法を紹介した上で、文字列型から数値型への「暗黙の型変換」により、SQLの実行が遅くなる可能性を指摘した。 この情報は、ネット上で検索すればすぐに見つかるものであるが、私自身試したことはなかった(なにせ暗黙の型変換などやりたくないクチなので)。 しかし、実験もせずに「SQLの暗黙の型変換はパフォーマンスが劣化する」と断言するのもエンジニアとしてどうかと思い、簡単なサンプルで実験を行ってみた。 実験には、Oracle Database 10g Express E
SQLの暗黙の型変換はワナがいっぱい
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月24日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、SQLにおいて「暗黙の型変換」を使うべきでない理由として、具体的な「ワナ」をいくつか紹介します。 数値項目に対するSQLインジェクション対策のまとめにて説明したように、RDBの数値型の列に対してSQLインジェクション対策をする方法として、以下の三種類が知られています。 バインド機構を用いる パラメータの数値としての妥当性確認を行う パラメータを文字列リテラルとしてエスケープする このうち、方法3を使うべきでない説明の補足です。具体的には、方法3には、「暗黙の型変換」が発生しますが、それが思わ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - kwatch/sqltempl8: Small template system for SQL in order to prevent SQL Injection (almost) perfectly
【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
SQLで木と階層構造のデータを扱う――入れ子集合モデル