ここ数カ月FilemakerとMySQLを、
Filemaker9より実装されたESSを使って接続し、
EC向けCMSを作っていました。
そのうえで、いくつかハマってしまったことがあったので、レポ。
（というか、実際は全部不確定要素ですけど・・・。）
まず結論。ESSはそこそこ使えるけど過信はしないほうがよい。
その理由
◆LONGTEXTが使えない？？（不確定要素）
LONGTEXTのカラムはFMでは「テキスト」のフィールドとしてマッピングされます。
私の環境ではなぜか、LONGTEXTがTEXTとして扱われ、
65,535バイトで切り捨てられてFM上で表示されました。
DB構築途中でTEXTからLONGTEXTへ変更したのが影響している可能性もあります。
この辺は未確認です。すみません。
◆リレーションが効かない？
MySQLのテーブルのキーでないカラムに対して、
FMのテーブルとリレーションすることは、
仕組み上できるようになっています。
見た目上一応動きます。
が、MySQL側のレコード数が増えてくるとそれなりに影響が出ます。
たとえば、FMのスクリプト内で、
FMテーブルからMySQLテーブルへ「関連レコードへ移動」をすると、
FMエラー101(レコードなし)が帰ることがあります。
おそらく、MySQL側にインデックスがないためレコードの取得に時間がかかり、
関連レコードなしと判定されるのではと思います。
私の場合、MySQLのテーブルにルックアップを指定しておいて、
関連レコードに移動し再ルックアップ。
関連レコードがなければ、FM側のレコードの値を利用して、
MySQL側にレコードを新規作成。
というスクリプトを作っていたのですが、
関連レコードがあるにもかかわらず、なしと判断され、
不要なレコードを作成してしまうケースに悩まされました。
対応策としては、
主キーでリレーションするか、
リレーションしたいカラムにINDEXを作っておくというのが手でしょう。
まぁ、そもそも、キーでもなくINDEXもないカラムでリレーションとか、
プログラマ的にアホすぎるだろって自分でも反省しています。
ちなみにレコードのインポートで、一致するレコードを探すときも同じことがおきます。
私の場合は、なでしこでCOUNT()関数を使って、MySQL側にSQL発行し、レコードがあるかなしかを判定させることでとりあえずその場をしのぎました。
◆MySQLのレコードをロックできない。
まぁ当たり前なんですが、必ず頭に入れておかなければならないことです。
複数人やさまざまなインターフェイスからMySQLのレコードを操作する可能性がある場合は、
FMでどうにかしようというのは考えないほうがいいでしょう。
編集中のフラグをMySQL側のテーブルに用意して、
そこに何かあるときは編集しないようにすれば一応はいけるでしょう。
ただ、やっぱりこれもFMだけで判定するのはよくないかなと思いましたので、
私の場合は、なでしこでSQL発行して、判断しています。
いまのところ私が困ったESSのハマりどころはこんな感じです。
別になでしこ開発コミュニティの回し者ではないですが、
やはり、なでしこプラグインがあることによって、かなり幸せになれます。
Windows版FMのDB構築する上で、なでしこは必須だろうと、改めて思いました。