2010年01月23日

RDBMS上でのテーブル定義

さて、外部SQLデータソースに移行する FileMaker テーブルの準備が完了したら、今度はそれに対応するテーブルを RDBMS (ここでは MySQL) 上に作成します。

FileMaker テーブルの各フィールドのデータ型に合わせて、MySQL テーブルの各カラムのデータ型を決めます。特に Text と Number については、そこに格納するデータに応じて、適切なデータ型を決めてやる必要があります。Date については FileMaker が日付のフォーマットを自動変換してくれます。

各テーブルには必ずプライマリキーを定義し、インデックスを作成しておきます。また、FileMaker 上でリレーションされるそれぞれのフィールドに対応するカラム=すなわち外部キーにも、必ずインデックスを作成するようにしましょう。レコード数にもよりますが、プライマリキーと外部キーへのインデックスを怠ると、FileMaker からのアクセス・パフォーマンスが明らかに低下します。



さて、実はここからが一番大変なところです。FileMaker は、テーブルの各フィールドをその名前でなく、内部的なID番号で管理しています。これにより、ユーザはテーブル定義にてフィールド名を変更しても、レイアウト上に置かれたフィールドへの対応が切れることがありません。またそのフィールドを使用しているスクリプトにも新しいフィールド名が自動的に反映されます。

ということは、FileMaker 上のテーブルを外部SQLデータベース上に移行するにあたり、フィールド名を同じにするだけではだめ(あるいは、フィールド名を同じである必要がない)のです。いくらフィールド名を揃えても、レイアウト上やスクリプトで使われている各フィールドには全く異なるフィールドが割り当てられてしまいます。

FileMaker の外部SQLデータソース機能というのは、MySQL 等にあるテーブルを新たに FileMaker に追加して、あたかも FileMaker 上のテーブルと同じように扱える、ということを目的としています。ですからこの使い方の範疇では、既存のレイアウトとの整合を気にする必要はないわけです。

しかし今回私がやろうとしているのは、既に FileMaker 上で使ってきたテーブルを MySQL に移行するわけですから、そのテーブルの各フィールドに関連したレイアウト・スクリプトがたくさんあります。それらを一つひとつ修正することは現実的ではありません。

すなわち、FileMaker が内部的に持っていたテーブル定義と同じものを MySQL 上に再現しなければならないということです。

基本的には、FileMaker はテーブル内のフィールドに対し、その作成順に「内部ID」を振っているようです。従って、MySQL 上のテーブルも、それと同じ順番でカラムを定義してやれば良いのです。

ところが FileMaker テーブルで、以前にフィールドを削除したことがある場合、その削除されたフィールドに該当する「内部ID」は欠番となってしまいます。なので、MySQL 上のテーブルに、その欠番に対応した「捨てカラム」を用意してやらねばなりません。しかし、FileMaker のテーブル定義のどこを見ても「内部ID」など見あたりません。

それではいったいどうすれば、各フィールドの「内部ID」を知ることができるのでしょうか。

それは、FileMaker でそのデータベースファイルの「修復」を行ない、その際に生成されるログファイルを見るのです。ログの中に、下記のようにフィールドを修復した際の記録が出力されています。
2010-01-12 12:11:13.522 -0800 Database.fp7 0 Recovering: field 'cycle_id' (1)
2010-01-12 12:11:13.523 -0800 Database.fp7 0 Recovering: field 'project_id' (2)
2010-01-12 12:11:13.524 -0800 Database.fp7 0 Recovering: field 'cycle_name' (3)
2010-01-12 12:11:13.525 -0800 Database.fp7 0 Recovering: field 'Planned Start Date' (7)
2010-01-12 12:11:13.526 -0800 Database.fp7 0 Recovering: field 'Planned Start Date Sort' (12)
2010-01-12 12:11:13.527 -0800 Database.fp7 0 Recovering: field 'Cycle Unique Name Check' (13)
2010-01-12 12:11:13.529 -0800 Database.fp7 0 Recovering: field 'Status' (19)
2010-01-12 12:11:13.529 -0800 Database.fp7 0 Recovering: field 'Complete Date' (20)
2010-01-12 12:11:13.530 -0800 Database.fp7 0 Recovering: field 'Cycle Last Modified' (21)
2010-01-12 12:11:13.531 -0800 Database.fp7 0 Recovering: field 'comments' (23)

このとき、'cycle_id' (1) とか、'project_id' (2) のように、フィールド名の後ろのかっこの中の数字がいわゆる「内部ID」に相当します。上記のサンプルでも、3の次が7だったり、その次が12だったり、欠番が存在していますが、それらのフィールドは既に削除されている、ということになりますね。

これを手がかりにして、欠番にあたる箇所に「捨てカラム」を用意し、MySQL 上でテーブルを定義してやれば良いのです。

【2010-1-29追記】
テーブルのプライマリキーには、FileMaker テーブル上でのシリアルナンバー・フィールドを当てることもできます。この場合、新しいレコードに対するシリアルナンバーを、FileMaker あるいは RDBMS のどちらで振ればよいのでしょうか。

他のシステムとの整合性、再利用性を考えると、RDBMS 上でシリアルナンバーを割り振るようにするのが順当でしょう。

ただし、FileMaker 側で新規レコードを作成する際に、関連するスクリプトが新規レコードのシリアルナンバー・フィールドに依存する場合は要注意です。もし新規レコードのコミット前に新しいシリアルナンバーが必要な場合、それは FileMaker 側で割り当てるようにしなければなりません。あるいは、新規レコードを一旦コミットして、RDBMS 側でシリアルナンバーが振られてから動作するように、スクリプトを修正してやる必要があります。


posted by Kojima at 10:26| Comment(0) | TrackBack(0) | External SQL Data Source | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック
×

この広告は180日以上新しい記事の投稿がないブログに表示されております。