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」に相当します。上記のサンプルでも、３の次が７だったり、その次が１２だったり、欠番が存在していますが、それらのフィールドは既に削除されている、ということになりますね。
これを手がかりにして、欠番にあたる箇所に「捨てカラム」を用意し、MySQL 上でテーブルを定義してやれば良いのです。
【2010-1-29追記】
テーブルのプライマリキーには、FileMaker テーブル上でのシリアルナンバー・フィールドを当てることもできます。この場合、新しいレコードに対するシリアルナンバーを、FileMaker あるいは RDBMS のどちらで振ればよいのでしょうか。
他のシステムとの整合性、再利用性を考えると、RDBMS 上でシリアルナンバーを割り振るようにするのが順当でしょう。
ただし、FileMaker 側で新規レコードを作成する際に、関連するスクリプトが新規レコードのシリアルナンバー・フィールドに依存する場合は要注意です。もし新規レコードのコミット前に新しいシリアルナンバーが必要な場合、それは FileMaker 側で割り当てるようにしなければなりません。あるいは、新規レコードを一旦コミットして、RDBMS 側でシリアルナンバーが振られてから動作するように、スクリプトを修正してやる必要があります。
