HonestyWorks TechNote

mysqlのサブクエリに問題があることはなんとなく見聞きしていたが今日はこれについて深く追求せざるを得ない機会があったので調べてみました。
自分なりに理解したので簡単にまとめてみるが、以下のブログの記事が素晴らしいので詳しくはそちらもあわせて読むと良いでしょう。

http://nippondanji.blogspot.com/2009/03/mysql_25.html

mysqlの実行計画を知るには

mysqlで実行計画を取得するには実行したいクエリーの前に EXPLAIN をつけるだけ。
実にシンプルだが、取得できるデータもシンプル極まりない(^_^;)

mysql> EXPLAIN SELECT COUNT(customer_id) FROM dtb_customer  WHERE  del_flg = 0  
AND customer_id IN (SELECT customer_id FROM dtb_order WHERE order_id IN 
(SELECT order_id FROM dtb_order_detail WHERE product_name LIKE '%とうもろこし%' ));
+----+--------------------+------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type        | table            | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+--------------------+------------------+------+---------------+------+---------+------+------+-------------+
|  1 | PRIMARY            | dtb_customer     | ALL  | NULL          | NULL | NULL    | NULL | 1834 | Using where |
|  2 | DEPENDENT SUBQUERY | dtb_order        | ALL  | NULL          | NULL | NULL    | NULL | 2023 | Using where |
|  3 | DEPENDENT SUBQUERY | dtb_order_detail | ALL  | NULL          | NULL | NULL    | NULL | 2163 | Using where |
+----+--------------------+------------------+------+---------------+------+---------+------+------+-------------+
3 rows in set (0.02 sec)

実行計画の読み取り方は こちら に詳しく載っています。

IN句はEXISTS句におきかわる

さて、上にあげたクエリーは IN句に二重にサブクエリーが入っている、ツッコミどころ満載のSQLである。(実はEC-CUBEの中でこのクエリーが使われている。)
普通は1番内側のサブクエリーから実行されていって結果が返ってくるという動きを想像してしまうしそのほうが効率がいいのは明らかだ。
ところがmysqlでは外側のクエリーから実行し、得たレコードについて内側のサブクエリーを繰り返し実行するという処理になる。
つまりIN句なしで検索した結果が3000行ある場合、その各行についてサブクエリーの走査が実行するされるのでとんでもなく時間がかかってしまう。

何故このようになるかというとmysqlのオプティマイザがIN句をEXIST句に置き換えてしまうため、サブクエリーが相関サブクエリーとなり、結果上に述べた実行計画になってしまう。

DEPENDENT SUBQUERY に注意

このように実行計画で DEPENDENT SUBQUERY となっているものについては、 nxn の走査が走ってしまう可能性があるのでできるだけ排除したほうがいいだろう。
できる限りJOINを使うように心がけたい。

なんでもCMS では「EAVモデル」というデータ構造を採用しています。
EAVとは Entity, Attribute, Value の略です。
この名称が一般的なのかは知りませんが、Magento というeCommerceシステムで EAVモデルという言葉が使われています。
http://4plus.jp/tech/2011/02/magentoeav.html

従来のRDBMSよるスキーマ構造とは大きく異なり、本来テーブルとして定義すべきものを全て Entity, Attribute, Value の3つのテーブルで管理します。（なんでもCMSではRecordというテーブルも使っています。）

これにより管理画面から自由にオブジェクト設定(＝データベースのテーブル設計)ができ、動的に変更が可能な構成を実現しています。メタデータがDBに登録されているので画面の生成なども容易に自動化できるわけです。
EAVモデルはなんでもCMSにとっては欠かせない要素のひとつなのです。

逆にEAVモデルのデメリットは

1. 正規化されたRDBMS設計のようにSQLでの取り扱いが簡単ではない
2. データ量が増えてきたときのパフォーマンス（特定のカラムにインデックスをつけたりとかできない）

といったことが挙げられます。

1についてはO/Rマッパー層で吸収するコードを書いたので、あたかも普通のテーブル設計のようにプログラミングすることができるようになりました。

2についてはメリットとのトレードオフということで割り切って考えています。
CMSでそれほどデータ量が問題になるとも思えないですし、データ量の多いオブジェクトは専用のテーブルを作るなどのハイブリッドな設計にすればよいかと思います。

EAVモデルはCMSとの親和性が非常に高いということに気づいたのがなんでもCMS開発のきっかけでもあります。

概要

日本語ロケールのダウンロードはこちら

LifeType はオープンソースのブログシステムなのですが普通と違うのは「ポータル型ブログシステム」だということです。つまり、1つのシステム内に複数のブログ、複数のユーザを作ることができ、ブログ:ユーザは N:N の関係になっています。
WordPressも3.1以降(?)になって複数のブログを１つのシステム内に作れるようになりましたが、最初からそのように設計されているのとそうでないのとでは後々差が出てくるとしたものです。
LifeTypeではサマリーページといって、システム内の全ブログの統計が見えるようなしくみになっています。
用途としては、以下のようなものが考えられるかと思います。

• アメブロやLivedoor Blogなどのようなブログポータルサイト
• 社内ブログシステム
• 多店舗型ビジネスのポータルサイトとして

etc.

このありそうでなかったブログシステムが気に入ったので日本語のロケールファイルを作ってみることにしました。
LifeTypeはきちんと多言語化対応されていて、サイト用と管理用２つのロケールファイルを翻訳するだけでサイトを日本語化することができました。（といってもあわせて1500行ぐらいある大変なものでしたが・・・）

ロケールファイルを翻訳していくとだいたいどんな機能があるかイメージできてくるので、そういう意味でも有意義な作業だったと思います。

ロケールの適用手順

LifeTypeをダウンロードして解凍したら locale というディレクトリを確認してください。たくさんロケールファイルがあると思います。ここと、この直下のadminというディレクトリに日本語ロケールファイルを配置します。

インストールプロセスは英語で進みます。 Step6 の Blog Conficurationのところで Languageの選択肢に「 Japanese locale file for LifeType 」というのが出てくると思いますのでそれを選択してください。

既に別のロケールでインストールした場合

既に別のロケールでインストールしてしまった場合も管理画面から変更することができます。
管理画面にログインし、「ADMINISTRATION」タブをクリックします。
中ほどにManage Locales というセクションがあるので、New locale をクリックします。
このページで「Scan Locales」というボタンをクリックすれば、localeディレクトリに手動で配置したファイルが読み込まれて選択できるようになります。

参考

• http://lifetype.net/
• 日本語ロケールのダウンロード

弊社では見積書や請求書の作成/管理に ZohoInvoice を使用しています。
これだけの機能が低価格で利用できるのでとても重宝していますが、

• 見積のタイトルを入力する欄がない （無理やりTermのフィールドをタイトルとして使用しています。）
• 一覧に見積のタイトルを表示できないので管理がしづらい
• ステータスが Draft/Sent/Deleted しかないので管理がしづらい

といった難点もありました。

見積書の数も増えてきてさすがにそろそろ管理の限界に近づいたので、ZohoInvoiceで公開されているAPIを使用してSalesforce上にデータを同期するようにしてみました。

一覧管理ができればいいので見積の明細までは同期せず、タイトル、顧客名、見積番号、総額などをカスタムオブジェクトに登録するようにしました。
ざっと以下のような手順です。

1. 見積管理のカスタムオブジェクトを作成
2. VisualForce ページを新規に作成して、初期実行メソッドでZohoInvoiceと通信、データを同期するプログラムを作成。
3. 上記ページをカスタムボタンに割り当て
4. ボタンをリストビューに表示

これで一覧性が良くなり、またステータスも細かく管理できるようになりました。

概要

「なんでもCMS」はWeb製作をするデザイナーさんが簡単にCMSを構築することを目的としたプロダクトです。
Web製作を請け負う課程で、お知らせや事例などちょっとした更新をするための画面やお問い合わせフォームの作成など、プログラミングが必要な部分は別途システム開発屋に頼む必要がありました。
「なんでもCMS」を導入することで上記のようなことは全てデザイナーさん自らが構築することができます。
そしてそれ以上のことも。。。

特徴

• 静的ページは通常通りFTP等で管理可能。動的更新をしたいページのみを管理画面から設定。
• 動的ページもサーチエンジンフレンドリーなURL体系 (ex. foo/bar.html)
• 既存のホームページをかんたんに更新可能にできる。
• 入稿する項目を自由に設定可能。そのためわかりやすい操作での更新が可能。
• 後からでも項目を追加可能。
• お問い合わせ等のフォームページにも対応。

エンドユーザーのメリット

• 更新用の画面がシンプルで直感的。更新すべき項目が明確なため迷わない。
• WordPressやMTなど、余計な機能が多すぎて慣れている人でないと使えない。「なんでもCMS」なら誰でも直感的に操作可能。

デモ動画を公開しましたのでよろしければご覧ください。
お問い合わせは こちら からお願いいたします。