Entry

Movable Type のスキーマをつらつら読む

2010年08月18日

このサイトで使っている Movable Type 3.36-ja のスキーマをつらつらと見ています。ちと古いバージョンなんだけれども,一応,ER 図に起こしてみてもいる。

で,ソースを読んでいないからなんとも言えないんだけれども,スキーマを見ていて非常に謎なのが,なぜか blog_id と entry_id を同時に持っているテーブルがあること。blog_id というのは,ひとつのブログサイトを表す mt_blog テーブルの主キーで,entry_id というのは ひとつのエントリを表す mt_entry テーブルの主キーです。mt_entry には entry_blog_id というフィールドがあって,こいつは mt_blog テーブルの外部キーになっています。

つまり,mt_blog と mt_entry には 1:n の関係があるわけです。ということは,mt_entry テーブルの entry_id が分かれば,そのレコードの entry_blog_id を引くことで,親となる blog_id を引くことができます。それじゃ,なんで blog_id と entry_id をひとつのテーブル(例えば,mt_comment テーブル)で同時に持つ必要があるんだろう……。これ,スキーマレベルでは整合性が取れなくなることもありうるんじゃないだろうか。

ちょっとかまととぶっているけれども,ひとつ考えられる理由としては,結合するテーブルをなるべく少なくするためなんだと思います。mt_comment テーブルの comment_id から,そのコメントが書かれたブログの blog_id を引くときに,mt_entry テーブルを結合するのはコストかかるから,直接 blog_id を mt_comment テーブル内に埋め込んでいる,と。mt_entry テーブルは,レコードの数が多いのが普通なのに対して,mt_blog テーブルは普通多くはありません(大抵はレコードひとつだけ)。mt_entry テーブルから所望のレコードを引っ張るには,割とコストがかかるはずです。しかし,だからといって blog_id を埋め込んでしまうと,mt_entry テーブルの該当レコードが指している blog_id と mt_comment が指している blog_id とで別々の blog_id を持つことができてしまいます。おそらくこれは,プログラムの制御で云々しているんだろうけれども,ちょっと怖い。

また,mt_trackback テーブルにある trackback_entry_id と trackback_category_id のフィールドもちと謎です。Movable Type では,カテゴリにもトラックバックを送れるから,それはそれでいいんだけれども,エントリへのトラックバックとカテゴリへのトラックバックのどちらもひとつのテーブルに収めているのは,ちと疑問。というのも,片方に値が入っているときは,片方は無効なわけだけれども,これはプログラムの制御を見ないと分からないからです。スキーマに隠れた条件があるのは,あまりよくないんじゃないだろうか。ま,細かい話なんですけど。

ずっと前にあたしが参加した某システムの開発では,外部キーすらまともに定義していない,かなりユルユルのスキーマを使っていたことがあります。当然のことながら,整合性の制御はプログラム側で行わなくちゃいけなくて,大変苦労しました。そのときは Servlet だったけれども,Movable Type のような Perl CGI で整合性の制御をしているとすると,プログラム側にそれなりのオーバーヘッドがかかってしまうんじゃないだろうか

ま,古いバージョンのスキーマだし,今さらどうこう言ってもあまり役に立たない話なんですけれど,とりあえずそんなとこ。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN