ファイルメーカーで商用ウェブサイトを構築する
第2回　なぜファイルメーカーでなければならなかったのか？（1/3）

ZDNet Macの実践ファイルメーカー連載の「歴史編」に続く第2回は、ファイルメーカーを選んださまざまな理由について解説します。

　前回は、ZDNetのなかにファイルメーカーベースの制作システムを導入していく経緯について解説しました。

　これだけのことをやるのなら、別にファイルメーカーでなく、Perlでも、PHPでも、ACCESS + SQL Serverでもよかったかもしれません。でも、なぜファイルメーカーでなければならなかったのか？　そこを考えてみます。

　ざっとあげてみると、次のような理由が考えられます：

• アイデアを構造にできる
• インタフェースを作り込むことができる
• プラグインの存在
• AppleScript：外部アプリケーションの制御
• クロスプラットフォーム
• 簡単に、堅牢なサーバを立てられる
• ミニマムの初期投資

アイデアを構造にできる

　ファイルメーカーの良さは、なんといってもとっつきやすさです。通常、データベースは「構造の定義」とかいう、非常に難しい手順を踏まなければなりません。そのための敷居は素人には限りなく高いものに思えます。ところが、ファイルメーカーでは最初は思い付く最低限のフィールドを決めておけばよく、そのフィールドはあとで追加したり、変更することが簡単にできます。

　私自身も、最初は「グローバルフィールド」や「リレーション」、「ポータル」といった構造的な用語はまるっきり分からない状態でスタートしましたが、これらの概念がわかると、それらを利用した仕組みを取り入れ、改良していくことができました。それでも、新しい仕組みを入れたからといって、一から作り直す必要はなく、機能を追加していくだけですんだのです。

　アイデアというのは、つまり、データベースのフィールド定義です。ZDNet Macの記事だったら、次のようなフィールドが必要だということは思いつくはずです。

• 記事タイトル：「アップル、Mac OS X 10.9 Konekoをリリースか？」
• 更新日：「2010年1月1日」
• 執筆者名：「松尾公也」
• 記事本文：「アップルコンピュータは、Mac OSの新バージョン、通称『Koneko』を今年のMacworld Expo/Osakaで発売する……。」
• 組織名「ZDNet Mac」
• ファイル名「applekoneko.html」

　実際のところ、最初作ったデータベースのフィールドは、この程度だったのです。それが今では膨らみ続け、100以上のフィールドをかかえた巨大なデータベースに変わっています。さらに、4個のデータベースとリレーションを張っています。いまでは、3万件近くのレコード数をかかえ、10数名がこのデータベースを利用していますが、これは上に示した、ごくシンプルなデータベースからリニアに進化したものなのです。

　ファイルメーカーは、フィールドの種類をあとで変更することができ、1つのフィールドに収容できる文字数が、可変長です（つまり、文字数をあらかじめ決めておく必要がない）。テキストの場合、約32,000文字までを1フィールドにおさめることができるので、ウェブ制作に使う用途であれば、ほぼ事足ります。最初に使ったフィールドの種類はテキストフィールドと日付フィールド、そして作業した順番をソートするために使った、時刻フィールドだけでした。

　これだけのフィールドがあれば、HTMLファイルを作って、特定の場所に保存することができます。保存する場所、最終的にアクセスするURLも、これらのフィールドを組み合わせて計算させることで、生成することができます。

　もちろん、最初からデータベース作りの達人で、すばらしい構造をもったデータベースを作ることができれば、ベストです。しかし、学びながらどんどんアイデアを膨らませ、機能を追加したり改良したりすることができるところは、ファイルメーカーのすばらしいところです。

[松尾公也, ITmedia ]

Copyright© 2012 ITmedia, Inc. All Rights Reserved.

前のページ | 1/3 | 次のページ