『ビッグデータ分析・活用のためのSQLレシピ』はデータ分析でSQLクエリを叩く人なら必読の黒魔術大全 - 渋谷駅前で働くデータサイエンティストのブログ
こちらの本をご恵贈いただきました。 ビッグデータ分析・活用のためのSQLレシピ 作者: 加嵜長門,田宮直人出版社/メーカー: マイナビ出版発売日: 2017/03/27メディア: Kindle版この商品を含むブログを見る 一般的なSQLの本というのはDB管理の一環としてのインフラエンジニア向けの技術書であることが多く、意外にもデータ分析を主目的としたSQLの使い方やクエリの工夫の仕方について書かれた本というのはあまり多くないんですよね。故に、多くのデータ分析者は難解なテーマを実現するクエリを書きたくても参考になる資料が乏しく、途方に暮れるわけです。僕もHive / Redshift / BigQueryのクエリを書きながら「こんな分析がしたいんだけど、それを実現できるクエリってないよなぁ。。。」と何度天を仰いだことか。 そんなところに突然降って湧いてきたのがこちらの新刊書。もう目次を見ただ
SQLとの付き合い方 - クラウドワークス エンジニアブログ
こんにちは、HuluよりNetflix派の田中です（ロゴがお洒落）。 みなさん、SQL書いてますか？ 私自身は未だに使う機会が多いことからもなかなか枯れない技術の1つだなと感じながら、日々愛着を持って書かせてもらってます。 ただ、触り始めた頃はわかってないことが多く、プログラミング言語とは勝手が大きく違うことからも、ある程度書けるようになるまでは時間を要した記憶があります。 正直それまでは、あまり好きにもなれませんでした。 今回はそんな経験から、今では好きと言えるレベルになっている「SQLとの付き合い方」をまとめてみました。 クラウドワークス開発におけるSQLとの関わり方 始めに、普段の開発でのSQLとの関わり方を簡単に紹介しておきます。 クラウドワークスの開発ではO/Rマッパー（Ruby on RailsのActiveRecord）に任せることが多く、素のSQLはさほど出てきません。 た
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
ひでぶろぐ。 cakephp使いの為のsql構文
[PR] 今日のニュースは？？ : 2ch自動まとめキュレクス [PR] 名言や格言をどうぞ！ : 名言満載！ [PR] 副業したい？ : 出張ホスト募集中 [PR] SEO最高峰のクオリティー : 知る人ぞ知る、SEOUP.com。テラプレミアムアクトは抜群におすすめ！ [PR] 口コミ対策 : 口コミでSEO対策。なんとびっくり、1円からご利用頂けます。 [PR] 出張キャバクラアゲハ : ちょっとした飲み会のお供に。デートのお相手に。 cakephpのfind all とかそういうのを使いまくれば、別にmysql文なんて理解して無くても良い。 ただ、ちょっとだけ凝ったsqlを発行するときにごりごり書くとそれだけで相当処理が重くなる。 今回は、cakephpを使っていてあんまりsql構文を知らない人のために、構文をまとめてみた。 updateAll で primarykey 以外の条件
ドメインロジックとSQL
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジッ
自分の脳だけでは扱いが難しい量／複雑さの資料を取り扱う方法
１．アタマを使わなければならない場面では、アタマだけで考えていては答えにたどり着かないことが多い 人のアタマのささやかなワーキングメモリは、あきれるほど小さい。 同時に取り扱うには多すぎる事態にすぐに陥る。 考えるためには補助用具（ワーキングメモリの補助）が必要だ。 といっても、紙とえんぴつがあれば足りる場面が結構多い。 ２．なぜ考えているとはいえないか？ 逆に手を動かさないならば、 自分では「悩んでいる」つもりでも、それではただ「困っている」に過ぎない。 考えるとは、頭に浮かぶ連想をただ追いかけることではない。 ３．一般的な忠告としては「考えるかわりに手を動かせ」 一般的忠告としては、「行き詰ったら、手を動かせ」 しかし忠告というのは、一般的過ぎて、何をすべきかを知らせてくれるが、どのようにすべきかについての情報は含まれない。 忠告はそれだけでは、ほとんどの場合、役に立たない。 補完する
忘れてしまったほうがいいSQLチューニングテクニックについて - 極北データモデリング
10年ぐらい前はJavaで文字列を連結するときは String ではなく StringBuffer を使ったほうが速いなんて言われてたんだけど、それがテクニックとして有効だったのは「StringBufferを使えばこれこれの内部動作になる」という関係が固定されていたからで、仮にJVMのリビジョンによってどっちが速いかがコロコロ変わったり、文字列の長さが一定以上になると突然あっちの方が速くなったり、みたいな状態だったら「文字列の連結はStringBufferの方が...」はテクニックとして成り立たなくなってしまう。 が、SQLについての言説の一部はまさにこの状態で、本来成り立たないことがチューニングテクニックとして語られていると思う。 そういうのを暗記するのはやめて実行計画を見ましょう、という話。 「INとEXISTSはどっちが速いか」の不毛 昔から「INを等価なEXISTSに書き換えると速
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
CSV 出力を１０倍高速にする方法 - オラクル・Oracle PL/SQL 入門
PARALLEL_EXECUTE パッケージ・モジュール ジョブを使用してマルチタスク処理させるためのフロント・モジュール このモジュールから UNLOAD のプロシージャを複数個、並列化して呼び出す。 仕様と制限 物理 ROWID を使用してデータの格納ブロックによってチャンク分割を行なっている。 論理 ROWID を使用する 索引構成表、外部表、および、ビュー などには使用できないため、別の分割方法を組み込んでカスタマイズする必要がある。NTILE 分析関数などは簡単なバケット分割方法であるがパフォーマンスを上げるひと工夫が必要だろう。 BIGFILE 表領域 に対してもソースの変更作業が必要となる(※2) DBMS_SCHEDULER 組み込みパッケージを使用しているため、Oracle 10g 以上の環境が必要。 ファイルの結合処理は含まれていない：ファイルを１つに結合したい場合には
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
・ヌ。シ・ソ・ル。シ・ケ。。・ェ・鬣ッ・�､ヌ・愠テ・ッ、キ、ニ、、、�･サ・テ・キ・逾����ホヌァ、ケ、�｣モ」ム」フハク
シ�ﾊフ。。・ヌ。シ・ソ・ル。シ・ケ。。・ェ・鬣ッ・� ニ簣ニ。。・愠テ・ッ、キ、ニ、、、�･サ・テ・キ・逾。コケ、�｣モ」ム」フハク エトカュ。。OS。。Windows NT 4.0 。。。。。。。。Oracle Oracle8 server セワコル。。ORACLE、ホ・゛・ヒ・螂「・�､ホ・�･ユ・。・�･ケ、ヒオュコワ、オ、�､ニ、、、゛、ケ SELECT V$SESSION.SID ,V$SESSION.SERIAL# ,SUBSTR(V$SESSION.MACHINE,1,20 ) ,SUBSTR(V$SESSION.PROGRAM,1,20 ) ,V$SESSION.USERNAME ,V$SESSION.COMMAND ,V$SESSION.LOGON_TIME ,V$TRANSACTION_ENQUEUE.LMODE ,V$TRANSACTION_ENQUEUE.REQU
Oracleセッション削除メモ(Hishidama's Oracle kill session Memo)
Oracle kill sessionメモ DB（Oracle）を操作する際に クライアントからDBに接続（connect）することによって、セッションが張られる。 1つのセッションの中でトランザクションを何個も実行することになる。 （コミットまたはロールバックによって1つのトランザクションが終了し、次のトランザクションが始まる） クライアントとDBが不慮に切断されたりすると、DB側でセッションが残り続ける（トランザクションが残り続ける。すなわちDBがロックされて、他のセッションからDBを更新できなくなる）ことがある。 そうなったセッションは強制的に削除しないと、DBの運用に支障を来す。 削除するにはsysdba（ユーザーsys）でDBに接続する必要がある。 セッションの確認方法（v$session） トランザクションの確認方法（v$transaction） セッションとトランザクションの
1つのSQL文で複数の表にINSERTする絶品テクニック（1/2） ― ＠IT
本連載はSQLの応用力を身に付けたいエンジニア向けに、さまざまなテクニックを紹介する。SQLの基本構文は平易なものだが、実務で活用するには教科書的な記述を理解するだけでは不十分だ。本連載は、著名なメールマガジン「おら！オラ！ Oracle - どっぷり検証生活」を発行するインサイトテクノロジーのコンサルタントを執筆陣に迎え、SQLのセンス向上に役立つ大技小技を紹介していく。（編集局） FOR...LOOP文を使って、いくつものSQL文でデータをINSERTしているPL/SQLプロシージャやプログラムをよく見掛けますが、実は1度にデータをINSERTする方法もあるんです。マルチテーブル・インサート（Multitable Insert）とはその名のとおり、1つのSQL文で複数の表にINSERTが可能になります。この最大のメリットは、やはりパフォーマンスです。では早速ご紹介します。 マルチテーブ
ロジックをDBMS側に寄せるデザインパターン - aike’s blog
O/Rマッパー（ORM）かSQLか、という話が一部で盛り上がっていたので追いかけていました。 ORMについては以下のような見方をすることもできます。 「最初からあらゆる要素をオブジェクト指向で設計、実装すると決めた新規開発システムならばORMは有力な採用候補」 「非オブジェクト指向で設計、実装されたシステムにORMはあまり向いていない」 なので、すでに存在しているデータベース上で別の新しいシステムを構築するような場合は、ORMはあまり向いていないと思います。 O/Rマッピングツールに対する誤解をときたい - ITは芸術だ 引用したエントリはとても冷静にORMの利点を説明している良記事です。 この記事の内容には全面的に賛同しつつ、自分としてはSQL側からちょっと書いてみたいと思います。 以前、試しにクエリに付随するロジックをできるだけDMBS側（SQL）に寄せるようにして開発したことがありま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Osquery
初級〜中級者のためのSQL特訓 - 忘れないようにメモっとく
SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か？
サービス終了のお知らせ