ファイルメーカーで商用ウェブサイトを構築する
第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 © ITmedia, Inc. All Rights Reserved.
前のページ | 1/3 | 次のページ