先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。

「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使うべきでないのか）ということについて、語ろうと思う。

続きを読む ≫

表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。

[フレーム]

内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に！」ということだ。

大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーできる範囲がとても広く、他のアプローチでは代替できないというちゃんとした理由がある。それ以外の選択肢が過去にはあまり流行らなかったのには理由があるのだ。

だから、単にNoSQLを使うだけでトータルの人件費を安くできる・・・なんてことはあり得ない！！絶対にだ！！

アーキテクチャを選択する立場にある人は、ぜひとも合理的な判断をしていただきたいと思う。

ところで、今回はオープンソースのRDBであるMySQLとPostgreSQLが合同で勉強会をするという、個人的にはエポックメイキングなものであった。ここ最近ではほとんど聞いたことがなく、個人的には合同勉強会に出席したのは初めてのことである。

本来であれば、会社や立場の垣根を超えて協業ができるのがオープンソースの利点であるはずである。であれば合同勉強会を阻むものは何もないはずだ。同じRDBというジャンルの製品であるので、話が通じることも多いだろう。面白いので関係者各位にはもっと開催する方向でお願いしたいと思う。

今日は最近出たリレーショナルデータベースの入門書を2冊紹介しよう。献本御礼！！

続きを読む ≫

Validation nightというイベントに呼んで頂いたので発表してきた。

続きを読む ≫

今日は徒然なるままにDB設計について思っていることを並べてみようと思う。

続きを読む ≫

今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。

続きを読む ≫

リレーショナルモデルを実践するには、ドメイン（≒データ型）を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。

というわけで今日のテーマはドメインである。

続きを読む ≫

とあるブログエントリで「ナチュラルキーを主キーにしてはいけない」という主張を見かけたのでこれに反論しておく。これはリレーショナルモデル的には明らかに間違った考えだからだ。

続きを読む ≫

最近、どうも安易に「NoSQLにすれば厄介なDB設計から開放される」と考えている人が多いように思えて仕方がない。だが待って欲しい。本当にNoSQLと呼ばれるデータベースを使えばアプリケーションの開発・運用の苦しみから逃れられるのだろうか。もちろん「そんなことは無い！！絶対にだ！！」と私は考える。今日はその理由について語ろうと思う。

続きを読む ≫

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

続きを読む ≫

新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。）

"リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。

さて、この疑問に対する正解は如何なるものだろうか？

続きを読む ≫

訳者、角 征典氏より献本御礼。「7つのデータベース 7つの世界」はそのタイトルの通り、7種類のデータベースソフトウェアについて解説したNoSQLの道標とも言うべき書籍である。7種類のデータベースとして紹介されているのは、PostgreSQL、Riak、HBase、MongoDB、CouchDB、Neo4j、Redisである。本書は非常にそそるタイトルであり、わくわくしながらページをめくった。だが、第2章「PostgreSQL」で期待感は打ち砕かれることになる。

正直なところ、この書籍について書評を書くのはどうしようか迷ってしまった。なぜならば、第2章の説明がかなり間違っているからである。そのため、書評を書こうとするとどうしても辛口にならざるを得なかった。献本して頂いた角氏にその旨を伝えたところ、それでも良いと快く了承して頂いた。本当に辛口になるのでその点は容赦して頂きたい。

続きを読む ≫

データベースのお祭りとも言える（？）INSIGHT OUT 2011でスピーカーとして参加させて頂くことになった。INSIGHT OUTは有料（当日2000円、事前登録1000円）のカンファレンスである。対象のデータベース製品はOracle、SQL Server、MySQL、PostgreSQLであり、海外からも著名なエンジニアが来てディープな技術の話が聞ける。（MySQLは4セッション）あのAsk TomのTomさんも来るというではないか！これが1000円なら超お買い得である。僭越ながら、筆者はそうそうたる顔ぶれに混じって、MySQL Clusterについて話させて頂く予定である。

INSIGHT OUT 2011

• 場所：UDX Conference（秋葉原）
• 日時：10/19〜10/21（筆者は21日発表予定）
• 参加費：2,000円（事前登録で1,000円）
• ホームページ：http://www.insight-tec.com/insight-out-2011.html
• ハッシュタグ：#insightout

ぜひお越しを！

dankogai氏のブログでバイナリデータとテキストデータの違いについて論じられているので、オトコ的にも少しコメントを加えてみたい。

バイナリーとテキストの本当の違い、それは「終わり」にある。
・「終わり」がはじめにわかるのが、バイナリー。
・「終わり」が来るまで「終わらない」のが、テキスト。
本質的な違いは、これだけである。

果たしてそうだろうか。

続きを読む ≫

CNetの記事によると、Googleが携帯電話で使われる絵文字を国際的な文字コード規格、Unicodeに収録しようというプロジェクトを進行中だそうである。

しかしこれはデータの設計という観点からすると極めて愚かな行為である。今日は声を大にしてこのような愚行に対して異を唱えたい。

続きを読む ≫

今年はSSDの台頭がめざましい。価格の低下、大容量化、そして高速化、さらには低電力化まで期待できるというからもうHDDの出番はなくなるんじゃないだろうかというぐらいの勢いである。しかしそんなSSDもデータベースで利用する時には気をつけてもらいたい。

続きを読む ≫

今日はデータベースを移行するべき場合とそうでない場合を見極めるにはどうすればいいか。見極めずにデータベースの移行に手をつけると失敗してしまうことになるが、自ら失敗を望んでいる人は居ないだろう。データベースの移行において失敗しないためにはどうすればいいか？

続きを読む ≫

データベース移行ではどのような作業を行わないといけないのか？全体的な流れを俯瞰的に見なければ、作業の見積もりなどが難しいことだろう。というわけで、今日はデータベース移行時に必要になる作業について7つのステップに分けて紹介しようと思う。言うまでもないことであるが、移行時には既存システムを直接いじるわけではない。（稼働中のシステムを直接いじるのは、走ってるクルマに乗り込むのと同じぐらい危険な行為である！！）開発用のシステムを別途用意して作業を進めるという前提で読んで欲しい。

続きを読む ≫

続きを読む ≫

人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。


と思ったそこのアナタ！！人生そんなに楽ではありません。

続きを読む ≫