はじめに ちょっととっつきにくいけどとっても便利な分析関数について、なるべく分かりやすく説明してみようと思います。Oracleを対象にしていますが、他のDBでもたぶん似たようなものでしょう（無責任）。 まず分析関数とは何をするものか、ですが、一言で言うと集合関数と同じ集計動作をそれぞれの行に制限範囲で実行するものです。ここでいう集合関数とは、MAXやSUMやAVG等、GROUP BYと共に使い行をまとめるて集計計算する関数ですね。分析関数は集合関数と同様の計算をしますが、集合関数と違い行をまとめません。それぞれの行で集計計算し結果を返します。ここが集合関数との大きな違いです。 また、集合関数ではGROUP BYの同じカラム値をもつ全行を一つに集計しますが、分析関数では集計対象となる行の範囲を任意で指定できます。関数に続くOVER句でこの範囲指定を行います。集合関数と分析関数は基本同じ名前な
Build beautiful charts in 2 clicks. Combine multiple charts in a Dashboard.
あなたが知らない既存機能があるかもしれません！ マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre
SELECT分で、WHEREで条件を指定して取り出したデータを、COUNTしたり、SUM（合計）したり、AVG（平均）したりする方法。 まずは、サンプルデータを作ります。 CREATE TABLE test ( id BIGINT , name TEXT , age SMALLINT ) ; INSERT INTO test (id, name, age) VALUES ('1', 'nagatomo', '31'); INSERT INTO test (id, name, age) VALUES ('2', 'yoshida', '28'); INSERT INTO test (id, name, age) VALUES ('3', 'honda', '30'); INSERT INTO test (id, name, age) VALUES ('4', 'okazaki', '31')
2015/2/13(金) 「外部キー Night」に参加してきました。 connpass http://connpass.com/event/11463/ 場所は千駄ヶ谷（代々木）のピクシブ株式会社さんです。 参加者は60人くらいでしょうか。 ・・・この勉強会のタイトル！そしてピンポイントなテーマｗ 惹きつけられずにはいられない！ そんな私も、SQLアンチパターン読書会で4章「キーレスエントリ」の紹介を担当したということもあり、外部キーには少し思い入れがある一人なのです。 外部キーNightのお供に、書籍「SQLアンチパターン」の４章、「キーレスエントリー」をお一つ、いかがですか～ / SQLアンチパターン読書会 「キーレスエントリー」 に参加しました http://t.co/Z116mYUDyI #sqlap #fk_night — makopi23 (@makopi23) 2015,
問題 こんなテーブル a があります。 create table a (id int, flag int); こんなふうにデータを入れて、 insert into a (id, flag) values (1, 1), (2, 1), (3, 0), (4, 0), (5, 1); こんなふうになっているとします。 select * from a; +----+------+ | id | flag | +----+------+ | 1 | 1 | | 2 | 1 | | 3 | 0 | | 4 | 0 | | 5 | 1 | +----+------+ なるべく単純な1つのSQLで、すべてのレコード数と、flag=1のレコード数と、flag=0のレコード数を取得せよ。 なお、サブクエリは使わないこと。 ヒント 集計を3つしたいので、こうなる？ select count(????), c
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
mysqlにおいてWHEREとJOIN ONで条件を指定した場合の違いがよくわかっていなかったのでまとめておく。 映画を表すmoviesテーブルと映画の日毎の再生回数を表すplaycountsテーブルがあるとする。 moviesテーブル +----+------------+ | id | title | +----+------------+ | 1 | MI3 | | 2 | Super Man | | 3 | Spider Man | +----+------------+ playcountsテーブル +----+-------+----------+------------+ | id | count | movie_id | date_at | +----+-------+----------+------------+ | 1 | 10 | 1 | 2012-12-16 |
インデックスを使うと何故早くなるのか 本ページではORACLEにおいてインデックスを使うと何故クエリが早くなるのか、またはなぜ速くならないのかを説明します。 なお、本ページでは索引構成表やビットマップインデックス等の特殊なデータ構造を持つオブジェクトは考慮しておらず一般的なテーブルとインデックスを想定しています。 前提知識 インデックスを使うとなぜ速くなるのかを理解するためには以下の前提を理解している必要があります。 ・ディスクアクセスはCPUアクセスと比較すると非常に遅い 一般的にはCPU処理時間がナノ秒単位であるのに対してディスクのアクセス時間はミリ秒単位であり、ディスクはCPUに比べて100万倍程度処理が遅いとされています。 したがって、クエリの処理時間はディスクアクセスが最も少ない実行計画が最も高速となる可能性が高いと考えられます。 ・I/Oの単位はブロックである ORACLEのI
予選突破 ISUCONというWebアプリケーションのパフォーマンス改善コンテストに参加し、予選突破しました。去年は不参加だったので2年振り2度目。(blog書くのもISUCON6振りで2年振りという... output無さすぎ) いやー実に楽しかった。やっぱりISUCONでしか味わえないモノがある。いつも何か新しい学びがある。 予選は両日共に問題なく進んだようですし、予選問題もいい問題でした。ベンチマーカーが詰まることもなく快適な予選でした。運営のみなさんありがとうございます。 久しぶりの参加だったので事前にISUCON7予選を解いてみたりconoha vpsでサーバ立ててansibleやfabric(deployに使っている)の動作確認をしたりして挑みました。ISUCON7予選を動かし始めたらあーこの感じやっぱり楽しいなと思って気持ちを高めてISUCON8に臨めて良かった。何を事前準備し
はじめに：Arelって何？ みなさん、Arel（アレル）ってご存知ですか？ ArelはActive Recordの内部で使用されるSQL生成ライブラリです。 Railsのクエリの書き方をググると、ときどきArelを使った実装例が見つかるので、見たことがある、もしくは何度か使ったことがある、という人もいると思います。 Arelをよく知らない人のために、Arelの利用例をちょっと見てみましょう。 たとえば「コメント文中に、"ruby"が含まれるユーザープロフィールを検索したい」という場合、Rails標準のクエリインターフェースを使うと条件部分のSQLを文字列で書く必要があります。（PostgreSQL環境を想定） Profile.where( "profiles.comment ILIKE ?", "%ruby%" ).to_sql #=> SELECT "profiles".* # FROM
Overview The Ruby on Rails web framework provides a library called ActiveRecord which provides an abstraction for accessing databases. This page lists many query methods and options in ActiveRecord which do not sanitize raw SQL arguments and are not intended to be called with unsafe user input. Careless use of these methods can open up code to SQL Injection exploits. The examples here do not inclu
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
こんにちは。レシピ事業部検索チームの薄羽 (@usulity) です。 続々と関連記事が投稿されていますが、日本とグローバルのクックパッドを統合しました。 この統合に際して、日本のクックパッドの様々な機能がグローバル版へ移植されました。今回は、移植された機能の一つである「人気のキーワード」について、移植した際にどんな課題があってどう解決したのかの一部をご紹介できればと思います。 人気のキーワード 人気のキーワードは、「クックパッドで最近よく検索されているキーワード」を集計して、ランキング形式で掲載する機能です。 日本版人気のキーワード このように、人気のキーワードは１時間おきに更新され、その時期・時間帯のトレンドを反映したようなキーワードのランキングになっています。 トップページの検索窓の下にも上位のキーワードが表示されており、人目につきやすい機能の一つです。 グローバル版人気のキーワード
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
＜この記事は「Money Forward Advent Calendar 2015」の8日目の記事です＞ みなさんSQL書いてますか？ 今回は、RDBでSQLを使って階層構造データをうまく扱う(ことに挑戦しようとする)方法に関するお話です。 数年前に出た「SQLアンチパターン」という本に書かれている内容で、大勢の方の記事でも取り上げられている話なのでだいぶ今更感が強いですが、私自身の忘備録としてまとめました。 というのも、実は私はこの記事の後半に書いた内容を使ってとあるシステムを設計していたのですが、諸事情あって結局そのシステムは日の目を見ずにお蔵入りになり、そのための供養を兼ねていたりもします。 階層構造データ まずこの記事でターゲットにしている階層構造を絵で描くと、このようなものです。 身近な例で言えば、ファイルシステムのディレクトリ構造がまさに階層構造になっていますね。 このような階
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
