テーブルの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。 こんなの使いません。 ブクマ用画像。
INとEXISTSは違います。 BETWEENと、不等号の組合わせなど、等価になる記述法はあるのですけれど、INとEXISTSは基本的に同じ結果を返すことが可能ですが、意味は違います。 この違いが分かるにはインデックスを理解する必要がありますので、まずは、インデックスのイメージをつけてください。 まずはイメージ ここでも、まずはイメージで考えましょうね。 あなたは先輩の結婚式の司会を頼まれましたとします。イロイロと準備がありますが、余興で歌を歌う人がいるとき、予めカラオケの番号を調べておくでしょう。 食事の間のBGMについては、ラブソングの入ったiPodをつないでランダムで流すことにしましょう。しかし、新郎新婦にとって（過去の恋愛経験上）都合の悪い曲があり、チェックしてはじいておくことにしました（なかなか、そつがない司会ですな）。 これらの処理をSQLにするならば……。 ■カラオケの番号を
インデックスが分かってない人が非常に多い。 現実にあった例で、60カラムあるテーブルに、前から3つずつの複合インデックスを20個作るとか、30カラムを1つの複合インデックスにするとか、意味が分かっていない人が非常に多くいます。 ※ 詳しい人へ。ここでは、インデックス = B-Treeインデックスと考えてください。 インデックスとは インデックスとは、そのままズバリ「索引」のことです。 身近な例ではカラオケがあります。いわゆるカラオケ本がインデックス。リモコンで押す番号が主キー、流れる音楽・映像が実レコードと考えてみてください。 カラオケ本は「歌手名順」と「曲名順」の2つは最低限あると思います。 これらは、 歌手名順は、「歌手名・曲名」の組み合わせの複合インデックス。 曲名順は、「曲名・歌手名」の組み合わせの複合インデックス。 と考えることができます。 想像してみてください。小学生でも「アン
どれほど優秀なコンサルタントに要件定義を策定してもらったとしても、どれほど時間を掛けて事前に仕様を策定していても、 開発中に変更や追加が発生するのはもはや常識です。その度にあらゆる修正が必要になるため、リミットが厳しければ厳しいほど 開発チームに負荷が掛かります。 特に大規模開発の場合、業界標準と盲目的に信じられているウォーターフォールはスケジュールや予算組みがしやすいなどのメリットがありますが、 事前の仕様策定に時間が掛かり、そこから開発に入るため恒常的に発生する仕様変更や追加によって要件定義まで戻って作業をし直す必要があるなど 多くの弊害があります。 また、アジャイルで組み立てたとしてもフロントエンドからバックエンドまでを全て修正する必要があるため、 場合によってはウォーターフォールよりも時間が掛かる場合もあります。 これ以外にも様々な制作手法が存在しますが、現代のIT業界のスピードに
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
「多くのOLTPデータベースは30年前の設計を基にしており、今日の“Webスケールな”データベースの負荷を想定していない。これら伝統的なデータベースは、処理時間の90％以上がログ、ロック、ラッチ、バッファ制御といったオーバーヘッドに費やされ、しかもそれらによって限られた性能やスケーラビリティしか実現できていない」 Ingresの開発者でありInformixのCTOなどデータベースベンダの要職を歴任したデータベース研究者の大御所、マイケル・ストーンブレイカー氏が開発したVoltDBはプレスリリースでこのように既存のリレーショナルデータベースの欠点を示した上で、インメモリデータベースをベースにこれらのオーバーヘッドを除去し、ACIDによるデータ一貫性を維持しつつ大きな性能向上とスケーラビリティを実現したと説明されています。 SourceForge.jpの記事「「NoSQL」を上回る性能を目指す
【お知らせ】 ＠IT自分戦略研究所 編集部です。 2010年5月28日、『ベンチャー社長で技術者で』を執筆する生島勘富氏を、エンジニアライフ コラムニストより除名いたしました。 今回の件について、多くの読者から問い合わせをいただきました。今回の処置について、生島氏には了承いただきましたが、「これまで行ってきた議論のまとめはしっかり行いたい」と、最終原稿掲載の依頼を受けました。 編集部で協議した結果、掲載すべきであると判断し、下記に生島氏より受領した最終原稿を掲載します。なお、この内容は＠IT自分戦略研究所の見解・意向を示すものではありません。 こちらで書いている文章は仕様書ではありません。過去をたどれる形で書かれていて、わたしの主張は常に一貫しています。ただでさえ長い文章に毎回毎回、前提条件は書けません。 が、とりあえずの前提は「業務系の仕事」です。SQLを他の言語と比べているのは、SQL
「数兆件のデータも対話的に、高速に分析できる」。グーグルは5月19日にこのような表現で新しいサービス「BigQuery」の登場を紹介するエントリを、ブログにポストしています。 グーグルが公開したBigQueryは、Hadoopやデータウェアハウスなどを用いて多くの企業が行おうとしている大規模データ（いわゆる「Big Data」）の分析を、グーグルのクラウドで可能にします。利用者はGoogle Storage経由で大規模データを転送し、SQLライクな命令によって抽出や分析を行います。 まるでグーグルが大規模データ処理のMapReduceをホスティングし、その機能をサービスとして提供するようなものがBigQueryといえます（ただし公開された「BigQuery」の説明には、内部でMapReduceを利用しているのかどうかの記述はないのため、MapReduce「的」なサービスと表現すべきかもしれ
世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
NVL 関数の内容 式 expr1 が NULL なら expr2 の値を戻す。Null Value Logic の略 COALESCE 関数の内容 、 NVL 関数を一般化した関数で引数に含まれる最初の 「非 NULL値」 を戻す。 COALESCE( expr1,…, exprN ) のように可変長の引数をもつ。 ⇒ コアレス：空き領域を連結してより大きな空き領域に変換 COALESCE 関数の追加説明と注意事項 COALESCE 関数の引数の数 (N) が 1 の場合にはエラーを戻す。 N = 2 の場合 … NVL(expr1, expr2) と同じ N > 2 の場合 … CASE WHEN expr1 IS NOT NULL then COALESCE( expr2,..., exprN) end と自己参照した内容と同じになる。 ちなみに NVL( expr1, NVL( e
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 如何様にも結論づけられる主観的な話になるので、宗教論争にしかならないからあまり書きたくないのですが……。いつも以上に、布教活動というか、独り言みたいなものですので、気楽に読んでいただければ。 一般的なシステムで、オブジェクト指向言語で処理を記述することと、SQLで処理を記述することについて、「保守性（拡張性）のために」というのが、オブジェクト指向言語で処理を記述することの金科玉条になっていますが、本当にそうでしょうか。 そもそも、業務システムの保守性とは 【保守性】 オブジェクト指向言語 ＞ SQL ＞＞ 混在型 が成り立つと、わたしは考えています。 オブジェクト指向言語推進派の方は、インピーダンスミスマッチをものすごく嫌う（わたしも嫌いですけど）。つまり、オブ
ベンチャー社長で技術者で:ベンチャー社長で技術者で: オブジェクト指向言語で処理したら保守性が悪い！. というのを目にした。要するに「OO言語＋RDBな組み合わせ」において、O\Rマッピングに頼らずにちゃんとSQLとストアドを書いた方がいい、と言うことである。 L.staｒは元々Java屋でそれからSQLに移ったので、未だに自分が両方をバックグラウンドに持つ人間だと思っている。O/Rマッピングのイ ンピーダンスミスマッチを解決する簡単な方法が実は無い、と言うぐらいには両方を理解している。だからこそ言いたいが、この文章、特定のDBが中央に鎮座していて、それがすべての中心になるような業務システムにおいては完全に正しい。ただし、元々そう言うシステムを念頭に置いて書かれた文章であるので、その点はちゃんと考えるべきだ。O/Rマッピングに頼り切って、SQLをきっちり書かない、ということをすると性能が出
はじめに 前回では、入れ子集合モデルという、リレーショナルデータベースで木構造を扱うための新しい方法論を紹介しました。このモデルは、RDB、SQLと親和性の高い優れたものではあるのですが、挿入など更新時に、無関係のノードまで変更対象としなければならないのが大きな難点でした。 そこで今回は、上記の欠点を解消する進化版のモデルを紹介します。この方法を理解していく過程で、私たちはRDBと集合論の結び付きの深さを再確認することになります。 ふだんこの連載は、1回完結の読み切り形式なのですが、今回に限り、前号の内容を前提としています。未読の方は、前号を先に読むと理解が増すでしょう。 稼働環境 すべてのリレーショナルデータベース もしも無限の資源があったなら 座標に整数のみを使う場合の限界 入れ子集合モデルの大きな欠点は、ノードを挿入（追加）するときに、自分より「右側」にある無関係なノードをもっと右へ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く