PHPとデータベースに関する5つの問題、とその解決法

IBMのサイトに、PHPから操作するデータベースに関してよく見られる5つの問題点とその解決方法が掲載されています。

データベースのデザインをする際、一般的に発生する問題点についての解説です。

で、肝心の5つの問題が何かというと、以下の通り。
Five common PHP database problems

1つめは古いPHPのコードでは直接、データベースにアクセスしているということ。コレに代わる手段としては、PEARのDBモジュールを使うか、あるいはPHPデータオブジェクト、PDOのクラスを使え、とあります。

2つめは、オートインクリメントを使わないということ。MySQLは基本的にレコード1つについてユニークなIDをオートインクリメントしているわけですが、これを活用していないというパターン。オートインクリメントを有効に使っていない場合、非効率的であるだけでなく、負荷も高くなるそうです。解決法は言うまでもなく、MySQLのオートインクリメントを使うこと。

3つめはデータベースを多重化すること。並はずれて巨大なデータベースであれば分割した方がよいと考えて多重化してしまいがちだが、通常の状態ではそれは必要ないとのこと。また、検索クエリーをいくつも走らせるよりも、多少コードが長くなってでも1つのクエリーで済ませるようにすれば、巨大なデータベースであっても問題ないらしい。この点については一見するとそんなことがあるものか！巨大なデータベースは分割した方が早いとどの本にも書いてあるぞ！と思いがちですが、実際に実行してみるとそんなことはない、とのこと。

上記3点目についてはGIGAZINEでも確かにそうなっており、クエリー数を減らした方がデータベースの分割などをするよりもはるかに負荷が低くなり、速度も上昇しています。MySQLは想像以上にその点では優秀っぽい。

実際に分割する必要があるのはどれぐらいのレベルかというと、mixiぐらいのレベルです。以下の記事が参考になります。

ミクシィのCTOが語る「mixiはいかにして増え続けるトラフィックに対処してきたか」：ITpro

やり方は以下のような感じ。

[ThinkIT] 第3回：データベースのスケールアウト（後半） (1/3)

また、通常のMySQL データベースの場合は下記のページに書いてあることを片っ端から適用できそうなのを使うと、結構いい感じになります。

MySQL 4.1 リファレンスマニュアル :: 5.2.13 その他の最適化のヒント

4つめの問題は、リレーションを使わないこと。リレーショナルデータベースはプログラミング言語のようなものではない。例えばアレイ（配列）などはない。代わりに1対多のリレーションを使用する。これによってアレイと同じ事ができる。つまり、問題となるのはプログラミング言語のノリでアレイをわざわざ作ってしまう場合。IBMのサイトにサンプルコードがありますが、要するに速度が遅く、メンテナンスしにくく、データベースのメリットを十分に生かせないものができあがるというわけ。解決法はただ一つ、伝統的なリレーションの技法に乗っ取ってスキーマを作り直すこと。

最後となる5つめの問題は、「n＋1」パターンと呼ばれるもの。エンティティのリストを検索すると、各エンティティの詳細を得るために1つずつ検索することになります。これを「n＋1」パターンと呼ぶ。というのも、非常にたくさんのクエリーが走ることになるため。1つのクエリーですべてのエンティティのリストを検索し。また次に発行されるクエリーで同様のことを行う、と。n個のエンティティすべてに対して行われるわけですが、このnが10とかならまだしも、1000などになると一気に破綻する、と。IBMのサイトに例となるダメコードのサンプルがありますが、一見するとクリーンなコードです。が、非効率的だ、というわけです。つまり走るクエリーの数を減らして効率化せよ、ということ。これはパフォーマンスに直結するが、案外、気づかない場合が多いそうです。

上記5つ、すべて基礎的なことばかりのようですが。これを理解せずにデータベースをPHPから適当に操作できるようにデザインすると、動いてはいるがなぜか著しくパフォーマンスが悪い、ということになるそうです。

あと、データベースとは何ぞや？と誰かに説明するのは非常に難しいと思いますが、以下のページを読ませればある程度は理解してもらえると思います。

リレーショナル・データベース概観