皆様

MySQLのファンダーの１人のMichael "Monty" Wideniusの
インタビューが
http://dev.mysql.com/tech-resources/articles/monty-2004.html
に載っています。日本語訳してみました。なかなか面白い内容だと
思いました。

岸本

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー


Michael "Monty" Wideniusはファウンダーで CTOでもあり、
MySQLデータベースの大部分の開発者です。MontyがMySQL　5.0
版の新しい機能に没頭する前に（そして娘と時間を過ごす
ために忙しくなる前に）MySQL 4.1版と現在のMySQL社
の状況を彼の目から語って貰いました。

(Q: 質問、Monty: Montyの答え)

Q: MySQL 4.1の開発は大体終わりましたが、4.1での
ユーザが期待できる主な機能はなんですか。

Monty: 一番の機能はサブクエリ、
prepared statementsとユニコードのサポートです。これらの機能
は今まで多くのユーザからリクエストされてましたので
提供できて非常に気分が良いです。

(編集者注: そのうちにMySQL 4.1版に関する、Montyが
触れなかったものも含め、新しい機能に関する記事を
お届けします。）

Q: サブクエリを実装する上で困難なことはなんですか。

Monty: サブクエリを実装には2つの部分からなって
います。古いクエリ・ハンドラーをリエントラントに
変更する必要がありました。これがサブクエリを実装する
ときの大部分の仕事となります。またサブクエリを 最適化
しやすいように標準のフォームに書き直すことも
重要です。内部的には多くのサブクエリをEXISTS (SELECT ...)
に変換する必要があります。この形式だと最適化しやすいです。

サブクエリの中にはこのほかにも(ANY, SOME etc..)の
ようにあまり難しくないものもありますが、工数は取られます。
非常に良く出てきて、他から独立しているサブクエリを
最適化してJoinと同じくらい速くなるすることが
重要です。それはかなり困難でしたが、うまく出来て
喜んでいます。ユーザは性能に満足すると思います。

Q: コードがおおきくなり、機能も増加し、開発チーム
も大きくなるにつれて、あなたの役割は変わりましたか？
いまだに全部のコードをリビューしていますか？

Monty:ここ2年ほどは実際に自分でコードを書く時間を犠牲に
して大分の時間をコードのリビューと会社の組織作りに使ってきました。
プロのマネージメントのチームが参加したので、私が一番
好きなことに時間を費やせます。それはアーキテクチャ、コード
を書くこと、コードをリビューすることです。
多くの有能な新しいメンバーとMySQL開発の計画や技術を議論をする
ことはすばらしいことです。

私はまだ全てのリリースの重要な新しいコードを全てリビューします。
これは他の人がリビューの前仕事をしてくれるので可能です。

Q: MySQL 5.0に関しては何か言ってくれますか。過去に
はストアド・プロシージャに関していろいろと発言しましたが、
5.0版には幾つもそのような機能が組み込まれています。
なぜ意見を変えたのですか。

Monty:　特に意見の変更があったわけではありません。
個人的にはアプリがデータベースをドライブするべきで
データベースがアプリの仕事をするべきではないと思ってます。
そうすればアプリがデータベースに依存することが減り
アプリがデータベースの制約されないことを保障できるから
です。

他のデータベースの開発者は異なった好みがあり、MySQLの
内部でストアド・プロシージャを提供できて嬉しいです。

Q: ストアド・プロシージャを使うときと他の方法を
使う方が良いときを教えてください。トレードオフは
なんですか。

Monty: データベースが関わる複雑な問題を解決する
には2つばかりアプローチがあります。アプリのロジックを
アプリ内に実装して、簡単なコマンドだけを使って
データベースにクライアント・サーバー形式でアクセスする方法。
またはデータベースの中でそのロジックを実装する方法です。

最初の方法の利点は（アプリにロジックを実装）アプリを
データベースに依存しないように設計できることです。
データベース言語の制限・制約にとらわれません。
SQLは非常に制限された言語で抽象化の機能を持っていません。
また、データベースでないコードの実行の方が速いです。
結果を格納する場合もクライアントのメモリー
の方が制限が少ないです。この方式だとデバッグも
容易です。

2番目の方法（データベースでロジックを実装する）には違った
利点とトレードオフがあります。 クライアントとサーバー間
でデータを交換する必要がないのでデータベース
内でオブジェクトを速く処理できます。簡単なアプリであれば
データベースを中心にアプリを容易に実装できます。ユーザ
privilegeをコントロールすることで、異なったアプリのロジック
のアクセスをコントロールできます。ストアド・プロシージャや
トリガーでデータのアクセスをコントロールすることで、データ
の完全性を保障できます。

Q: ストアド・プロシージャはサーバー拡張機能や
user-defined functionと比べてどうですか。

Monty: MySQLを使用してデータベースにロジックを実装するには
いくつかの方法があります。いままでにある方法は
ストアド・プロシージャを利用することです。これはパースされた
クラス・オブジェクトをアレーとして格納され、速く実行できます。
ストアド・プロシージャはループ、ロジック、関数呼び出しなどの
必要な複雑なタスクの際に便利です。

そのほかに、User Defined Functions (UDFs)を使用することも
できます。これはC/C++で実装されており、必要なときに
ダイナミックにリンクされます。UDFは高速な処理が必要で
結果が引数にのみによっているときに便利です。

更にMySQLのPROCEDURE ANALYSE()関数のような
サーバ拡張機能も使用できます。これはMySQL 5.0ではCHANNE
と名前を変えます。サーバ拡張機能は リトリーブしたデータに
なんらかの前処理または後処理をするときに便利です。通常
SQLでは困難。マニュアルに良い例が載っています。この例の
ソースコードをリビューするとサーバー拡張機能でなにが
できるかがよく分かります。

最後にいま1つの方法はMySQLに新しいテーブルハンドラーを
追加することです。この方法はMySQLから外部のデータに
アクセスする時またはデータを圧縮した形式で格納するなど
の特別の必要があるときに便利です。またMySQLサーバを新しい
コマンドを追加して拡張することもできます。しかし、これは
今までに述べた方法が問題解決にならなかったときに限ります。

Q: エンベデッドドのアプリはどうですか。

Monty: これはシングル・ユーザアプリかエンベッデッド
アプリに向いたアプローチです。この場合アプリとデータベース
を同じアプリ内に結合します。例えば、アプリを
エンベッデッドmysqldライブリーとリンクすることです。
この機能を使うとMySQLを密にエンベデッドしたアプリ
を使用するのに便利です。クライアント・サーバー
のモデルのようにトレードオフと利点があります。但しこの場合
データベースのオブジェクトの処理は速くなります。アプリケーションと
密接に結合していますから。

Q: 今年のユーザ・コンファレンスは成功裏に終わりまた
10月にはMySQLの素晴らしいギーク・クルーズがありますね。
このクルーズにはあなたのほか David Axmark, Brian Akerそのた
の MySQL の重鎮が参加しますね。どのようにしてこのイベント
を考えたのですか。

Monty: 以前Linux のギーク・クルーズに行ったことがあり
非常に役に立ちました。何日もLinuxの立役者の人々とLinuxの問題
とアイディアを語り合うのは楽しいし、非常に有益でした。

同じことをMySQLのユーザの皆様に提供したいと思いました。
皆様とMySQLについて議論したり学んだり、実際に役立つヒントや
解を提供できたらと思っています。クルーズの間は時間は
ふんだんにあります。参加されるユーザの皆様の問題を解決
するための議論にあてる予定です。

こういったクルーズを企画したもう1つの理由はユーザの皆様
とお会いする機械を得ることができ、そしてユーザの
皆様がMySQLの製品になにを求めておられるかを理解して、
将来の製品に反映させたいからです。

Q:　ベンチャーキャピタルが入ってMySQLどうは変わりましたか。
MySQLは本当の意味でオープン・ソースのルーツを守れそうですか。
それとも、ビジネスに焦点をあてるように圧力がかかっていますか。

Monty: ベンチャーキャピタルが入ってもあまり変わりません。
変わったことと言えば、もっと人を雇えるようになったことです。
今の問題は多くの人がMySQLに参加しているので、全員にMySQL
の創始のスピリットを知って貰うのが困難になってきていることです。
これは普通の会社より困難なことです、なんと言ってもMySQLは
本当の意味でバーチャルで社員が世界国中に散らばっていますから。

しかしながら、私はMySQL AB は真の意味でオープン・ソース
のスピリットを保持しながら、ビジネスとしても展開できると
思っています。オープンソースとコマーシャルを結合させること
でどちらの良いところも得ることが出来るからです。
---------------------
Zen Kishimoto                        zen@xxxxxxxxxx
IP Devices, Inc.                       (408) 567-9391
2175 De La Cruz Blvd., Suite 10  (801) 720-8847 (FAX)
Santa Clara, CA 95050