今日は徒然なるままにDB設計について思っていることを並べてみようと思う。 ようやくWEB+DB Pressの次号の原稿を書き終えた。2年間の連載であるが、来年はプライベートが忙しくなる予定なので、連載はこれにて終了とさせてもらうつもりである。 「なぜ人はリレーショナルデータベースを使いこなせないのか」 このところ執筆や講演を通じてリレーショナルモデルについて説明する機会を色々頂いているが、それらの活動の根源となっているのが、この素朴な疑問である。その疑問をパワーにしてこれまで活動を行なってきた。 現時点での自分の回答は「データベース設計が難しいから」である。もちろんリレーショナルモデルそのものの難しさというのもあるが、それよりは「適切な使い分けができていない」ということが大きいように思う。言葉を変えると、リレーショナルモデルを適用すべきデータとそうでないデータの判断ができていないからDB設

本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up

最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ まとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。 攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ

今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で

リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性（≒カラム）に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。 リレーショナルモデルにあるのはナチュラルキーだけリレーショナルモデルには「サロゲートキー（代理キー）」という概念はない。まずこの点に注意して頂きたい。サロゲートキーとは、データベースアプリケーション開発において実用上必要とされる機能であって、本質的には不要のものである。リレーショナルモデルでは、いわゆるナチュラルキーというものがあれば機能的には十分だからだ。 そのためにはまず「キー」という概念が何を指し示すかということについて正しく理解しなければならない。リレーショナルモデルではキーと呼ばれるものは候補キーとスーパーキーという2つの概念だけである。「タプル（≒行）の値を一意に決定することができる属性（≒カラム）の集合」の

先月、Dbtech Showcaseで松信さんがデータベース技術の羅針盤という講演をされた。残念ながらプレゼンそのものを観に行くことはできなかったが、その前の日に松信さんと一緒に昼飯を食べたとき、講演のあらすじについては伺っていた。その際にも同じようなことを松信さんには言ったのだが、スライドを見直した上で改めて自分の意見をまとめておこうと思ったので筆をとることにする。 なお、このエントリではスライドに書かれているトピックについて語るので、まだ松信さんのスライドを見てない人は先にスライドに目を通してから本エントリを読んで欲しいと思う。結論は全く違った方向に進んで行くが、その点は了承して頂きたい。 あなたに選択肢はあるか？ひと握りの天才なら自分の興味のある分野を開拓することができるだろう。あるいはすでに成功を収めた人であれば転職に困ることはないので、成功しそうな会社に乗り換えることもできるだろ

最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。 トランザクション先日、リレーショナルデータベースにおけるDB設計についてセミナーで解説したばかりだが、リレーショナルデータベースにおけるデータの整合性は何もDB設計だけが担保しているわけではない。リレーショナルモデルと同じかそれ以上に欠かせないのがトランザクションだ。 トランザクションがあるおかげで、トランザクション終了後のステータスは「成功」か「失敗」の2つしかないということが保証される。すなわちオール・オア・ナッシングだ。もしトランザクションの途中で何らかの

DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと

徳島オープンセミナーというイベントに招いて頂き、MySQLの運用まわり（？）の話について話す機会に恵まれた。運用といいつつ運用以外の話も色々混じっているが、平たく言うと「MySQLを使う上で躓きやすいポイント」というのが今回のお題である。セミナーで用いた資料を公開したので気になる人は参考にして欲しいと思う。 以前岡山へ呼んでいただいたときも感じたのだが、やはり休日に勉強会へ参加されるだけあって、皆さん勉強熱心である。首都圏のように毎日何かしらの勉強会があるというような恵まれた環境は、徳島にはないかも知れない。だが、スキル向上に対する真剣な姿勢は勝るとも劣らないように感じられた。 懇親会では、LibreOfficeの榎氏と色々と意見を交換させて頂いた。（というより二人でかなり話し込んでしまった感がある。）何を隠そう榎氏とは初対面だったのだが、榎氏もソフトウェアの自由を大切だと考える言わば同志

皆さんは普段音楽を聴いているだろうか。音楽業界が縮小していると言われて久しいが、私自身は音楽は嫌いというわけではない。昔から邦楽は好きではなかったので、邦楽に費やしたお金は非常に小さいが、音楽はむしろかなり好きな方だ。集中したいとき、余計なことを考えずに目の前のことに取り掛かりたいとき、行き詰まったとき、気分を変えたいとき、そんなとき手軽で役立つのが音楽だ。BGMを流すだけで仕事が捗るなら安いもんである。 今日は私が普段聴く曲の中から、開発者の皆さんのコーディングが捗る（と思われる）曲を10曲紹介したいと思う。なお、捗るかどうかは個人差があり、万が一捗らなくても保証はできないのでその点はご了承頂きたい。本エントリにはオチはないのでその点も悪しからず。 1. Return Value - General Fuzz ズバリ、返り値のテーマソングがこれだ！！その名も「Return Value」

毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ

先日、別のエントリでも書いたが、実は最近ノートPCを新調した。以前使っていたものが購入後3年経過し、サポートが切れたからだ。サポートに従事するものとして、やはりサポート期間というものは大事にしなければならない。（ちなみに、以前のマシンも壊れているわけではないので、クッキーを焼いたりするのに大いに役だってくれた。メインマシンが壊れるなど、いざという時にはいつでも活躍できるようスタンバイしてる感じだ。バックアップがあるのはやはり安心である。） というわけで、本日は新しいマシンについて何故これを選択したかという話や、設定などを紹介したいと思う。 外観など今回購入したのはThinkpad W530というモデルである。早速フリーソフトウェア財団のステッカーを貼った。白地のステッカーは黒によく映える。 インテルインサイドやWindowsロゴのステッカーは邪魔なので速攻で剥がした。邪魔者がなくなってスッ

既にブームが過ぎ去った感があるが、クッキークリッカーというゲームが流行っているらしいと聞いたのが先月のこと。本の虫のエントリを読んでからだった。それまでもTwitterのTL等でクッキークリッカーという単語は目にしていたのだが、全く興味もなかったので、「これってブラウザのクッキーをアレするイケナイゲームなんだろうか。物騒なもんが流行ってんなー」ぐらいにしか思っていなかった。ところが、江添氏があまりにも熱くクッキーについて語っているので、何となく興味が湧いてしまった。そしてブラウザのクッキーをアレするゲームではなく、単なるブラウザゲームであるということも理解した。江添氏の文章を見て思ったのは、「そんなにも面白いのか。」ということだった。 そんな折、友人がクッキークリッカーをやっているというのを知り、俺のハートにも火がついた。 「友人をぶち抜いてやる！」 ということでクッキークリッカーを始めた

もう2年以上前になるが、以前「MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック」というエントリを書いた。 エントリに書いた内容はそれなりにコンパイルの高速化に寄与はするが、実は測定方法は正しくなかった。このことについて、いつも冷静さを失わない奥一穂氏から、いつもの冷静さで指摘を頂いた。 奥さんの言う通りである。指摘をもらってから気がついた。反省した。それからからずっと「まっとうにコンパイルして30秒を切る方法」を模索してきた。そしてついに、ccacheを使わずにまっとうにMySQL 5.5のコンパイルを30秒未満で実行することが出来たので、その方法を紹介しようと思う。 速いマシンを買う いきなり身も蓋もない解決法だが、ぶっちゃけこれが一番効果的である。実行するべき処理が決まっていれば、最終的にCPUの実行速度によって処理時間が決まってしまう。 実は最近PCを新調したの

我らがリチャード・ストールマン氏（以下、敬称略）がGNUプロジェクトを孤軍奮闘ながら発起してから30年を迎えた。30年前と言えばWindowsすら無かった頃であり、コンピュータの世界は今とは全く異なっていただろう。「だろう」というのは筆者が当時まだ子供であり、その頃の業界について伝聞でしか知らないからである。 GNUプロジェクトは言うまでもなく、自由なソフトウェアによるオペレーティングシステムを作ろうという一大プロジェクトである。今のようにインターネットもなく、容易に支援も得られそうにない中で、独りでOSを創りあげようなどと起ち上がるのは如何に無謀なことであったか。しかし、その無謀のおかげで今日のソフトウェア業界の姿があるのは間違いない。 今日はGNUプロジェクトの重要さについて、改めて語ろうと思う。 GNUなくして今のインターネットは無かった これまで、GNUプロジェクトが果たしてきた役

昨夜、MySQL Cluster Casualにおいて、「カジュアルにMySQL Clusterを使おう」というタイトルで発表をした。その資料をスライドシェアにアップロードしたので、カジュアルにMySQL Clusterを使ってみたい人は参考にして頂きたい。 SlideShareではフォントが何やらおかしいので、資料をダウンロードして頂けると幸いである。 「 MySQL Cluster をカジュアルに使えるわけないじゃないですかｗｗｗ」 という声もあったようだが、自分がカジュアルだと思えばそれがカジュアルなのだ！！ 発表では、5分程度でMySQL Clusterのインスタンスをインストールするデモを見ていただいた。如何にカジュアルに使えるソフトウェアであるかということを、お分かり頂けたかと思う。カジュアルに使い始めてカジュアルにはまる・・・というオチはないと信じている。 転ばぬ先の杖という

この本を手に取ったのは単に売れているという理由からではない。むしろ話題になっても「なんかミーハーなタイトルだなー」ぐらいにしか思わず、あまり興味がわかなかった。 ところが、先日同僚の木村氏に誘われて参加した飲み会で、なんと著者の西内氏と話すという幸運な機会に恵まれた。西内氏は話が非常に上手で、ユーモアのセンスや頭の回転の速さ、そして匂い立つリア充臭を醸し出していた。著者に興味がわけば、著書にも興味がわくのが人情である。そして読んだ結果、とても面白い本だったので皆さんに紹介しようと思う。 統計学のいろはが分かる本書はミーハーなタイトルとは裏腹に、ストーリーに沿ってとても上手に「統計学のエッセンス」を伝えてくれる。専門書ではないので統計学のディテールには踏み込まないものの、要点を的確にピックアップしており「統計学ってどんなもの？どんなふうに使うの？」というクエスチョンに見事に答えている。一般向

人気ブログ、Life is beautifulの著者である中島氏が、『プログラミングは「教わる」ものか、「学ぶ」ものか？』というお題に対して回答を述べている。回答の要旨はこうだ。 わたしの答えは、「“教わる”のではなく“学ぶ”もの」です。 わたし自身が、独学でやってきましたから。高校生のころ、『TK-80』を組み立てて初めてプログラムを書くようになってからずっとです。大学ではプログラミングを“教わる”授業も受けましたが、残念ながら仕事には何も役に立ちませんでした。 社会人になってMicrosoftでWindowsの開発にかかわった時も、まずやったのはひたすらソースコードを読む作業。誰かにプログラミングを教わったという記憶がありません。 正直なところ、この回答には異論があるし、これからコンピュータについて学ぼうとする人にとっても弊害があるように思うので、今日はそのことについて語ろうと思う。

本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー（連載はVol.68〜）を購入して頂きたい。 本日発表したス