SQL をはじめて触ったとき、exists 述語と並んで直感的に理解しずらかったのが ALL や ANY を伴った比較。 WHERE 句において単体の値を比較するのは問題ないけれど、 「すべての XXXX と比べてどうか？」 とか、「少なくとも 1 つの XXXX と比べてどうなのか？」 となるとイメージしずらくなる。 量化 – Wikipedia によると、 全ての人間の言語は、完全な数体系がない場合でも、量化を利用している（Wiese 2004）。例えば、日本語での例は次の通りである。 「全ての方針に目を通す必要がある」 「川を渡っている人のうち何人かが白い腕章をしている」 「私が話した人々のほとんどが、誰に投票するか決めていなかった」 「待合室の誰もが小沢氏に対する少なくとも1つの不満を持っていた」 「クラスの誰かが、私の出した全ての問題に答えられるはずだ」 「多くの人々は賢明である

まず、ROW_NUMBERを使う場合には、特に悩む必要はありません。ORDER BYのキーに追加しましょう（リスト3⁠）⁠。実行結果は図2です。 リスト3　主キーが複数列の場合(ROW_NUMBER) SELECT class, student_id, ROW_NUMBER() OVER (ORDER BY class, student_id) AS seq FROM Weights2; 図2　リスト3、4の実行結果 class student_id seq ----- ------------ --- 1 100 1 1 101 2 1 102 3 2 100 4 2 101 5 2 102 6 2 103 7 一方、相関サブクエリの場合はどうでしょう。いくつか方法があるのですが、私が最もシンプルと思うのは、複合キーを文字列とみなして連結し、強引に1列のキーに作り変えてしまうことです。そ

ER図の表記法として、IE表記とIDEF1Xの2つが良く使われています。 それぞれカーディナリティの表し方が違うし、どちらもあまり直感的じゃない気がします。 分からなくなった時に参照できるように、それぞれのER図でカーディナリティを並べてみました。 なお、ER図はA5:SQL Mk-2を使って書きました。 親エンティティ側のカーディナリティが 0 or 1 の場合、子エンティティ側とは違った菱形の記号になる事に気が付いたので、画像を差し替えました。 親が0というのは、非依存な関係の場合にのみありえるので、菱形は独立エンティティの場合にのみ指定できるという説明を見かけたけました。 ツール上は依存エンティティでも 0 or 1 に指定できて菱形も出るけど、たぶんツールではそこまでチェックして無いということなのかな。 IDEF1X “P” (for positive) is placed bes

SQLの「相関サブクエリ」がわかれば・・・ 巨大なSQLが，迷わずに読めるようになる。 「関数」のような，便利なサブクエリを書けるようになる。 以下では， 「相関サブクエリ」とは何か？ 普通のサブクエリ（非相関サブクエリ）やJOIN操作とは何が違うのか？ 多重にネストされた，巨大なSQLの読み方は？ という点を論じる。 サンプルデータ，および全体の方針 （１）サブクエリ無しでJOIN （２）INで非相関サブクエリ （２）の補足：サブクエリを「関数」と考えてみよう （３）EXISTSで相関サブクエリ 他のサンプル 巨大SQLの読み方 サンプルデータ，および全体の方針 まず，相関サブクエリの説明のために，以下のようなテーブルを例として取り上げる。 table1が，普通のデータ table2が，マスタデータ（ホワイトリスト） 「マスタに一致しないレコードをはじく」という操作をしたい。 方法は３パ

こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL

はじめに システム構築においてデータベース設計は不可欠です。そこで多くの方がデータベースの設計技法について書籍で学んだりするのですが、なかなか身についたと感じられないことも多いのではないかと感じます。 その理由は、実務で任せられる機会というのが少ないからというのが大きなものとして挙げられます。データベース設計というのは、やはり重要な箇所ですから自然と経験のある人に任せられることが多いのが実態です。しかもデータベース設計を担当するのはプロジェクト全体の中でもごく少数だけになりますから、なかなかチャンスが巡ってきません。 しかし、それを嘆いているばかりではスキルが身につかないのも道理です。そこで身近にあるものを何でも手当たり次第にデータベース設計のネタにしてしまうことで、コツコツと地力をつけていこうというのがこのシリーズの主旨です。 合言葉は、「表組みを見たらERDを描け！」　。では、張り切っ

今回のテーマはデータベースエンジニアの必須知識の1つである「正規化」です。正規化は、リレーショナル・データベースのテーブル設計を行ううえで非常に重要なテクニックであり、データベースを設計、実装したことのある方なら一度は正規化に触れているのではないでしょうか。 それほど基本的な知識であるにもかかわらず、正規化を説明できる人はなかなかいません。多く聞かれるのが「何となくテーブルを作ると自然に第3正規形になる」とか「実務上は第3正規化まで行えば問題ない」というものです。 ではなぜ「第3正規化まで行えば問題ない」のでしょうか。本稿ではひととおり正規化について確認しながら、あまり触れられることのない第3正規化より先の正規化を紹介して、この疑問に答えていきたいと思います。 正規化の位置付け 正規化は、データベース設計全般にかかわる基礎知識ですが、特に論理データモデリングの作業の中で必要になります。本稿

主な内容 --Page 1-- ▼SQLとT-SQLについて ▼SQLの機能分類 --Page 2-- ▼SQL Server 2005を利用してみよう ▼Management Studioを利用する --Page 3-- ▼初めてSQLコマンドを発行してみる 本連載は、SQL Server 2005を利用しSQLの基礎からストアドプロシージャの作成までを、順序立てて解説していきます。読者対象はSQLに初めて触れるような方を対象としています。ちょうど連載が春からの開始となりますので、新人プログラマの方々はこの機会にぜひSQLをマスターしてください。また、本連載ではSQLを網羅的にとらえるよりも、分かりやすく実践的な内容を記述していきます。ツールの簡単な使い方から各種構文まで扱いますので、各回で取り上げた内容をきっかけとして、SQL学習を進めていきましょう。 SQLとT-SQLについて SQ

テーブルの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。 こんなの使いません。 ブクマ用画像。