FileMaker トランザクション

FileMakerはiPadやiPhoneなどの端末を利用できるGoが出来てから、今まで敬遠されてきた方も、新たに採用されたり若干戻ってきたりしているらしいです。
そうすると、口々にトランザクション制御についての質問をされているのですが、たぶん、OracleやMySQLを使用されてきた方々は、当然の疑問かと思います。


正直な話、FileMakerの性質上、トランザクション制御を求めるのは僕個人的には違うのかなという気がしています。

FileMakerの開発が早い理由のひとつとして、データの確定さえしていれば、おおよそ既に内部で一貫性にて処理されており、SQLでいう、ロストアップデートやノンリピータブルリード、ファントムリードが発生しない作りになっていることです。（ダーティリードはロールバックしても間違ったままのデータ状態で、FMの場合は別途ロールバックを仕掛けないとそもそも起こらない）
ACID特性でたとえると、Consistencyに相当するのでは・・・と思います。



＜トランザクション＞

トランザクションとトランザクション制御とは意味が違います。

トランザクションとは、たとえば、入庫テーブルの入庫数が更新されれば、在庫テーブルの数量が変わる。売上明細に商品と数量を追加すれば、売上の合計が変わるなど、お互いの関係・依存する一体の処理をいいます。　担当マスタや商品マスタなどとは扱いが違うものです。
始めての方は、販売管理や入庫管理などの入力される明細などの箇所、と思っていただいて良いのかと思います。FileMakerはデータが確定されれば、一貫してテーブル間でデータが連動されて更新されます。



すなわち、SQLのような隔離性水準（更新処理）を指定する下記の



SET　TRANSACTION

　　ISOLATION　LEVEL

　　　　　Read Uncommitted　または

　　　　　Read Committed または

　 　　　Repeatable Read　または

　　 　　Seriaｌizable



の様な設定は、まったく必要ないということです。



＜トランザクション制御＞

トランザクション制御とは、トランザクションデータを確定（コミット）させたり、なにか問題が発生したときは取り消す（ロールバック）処理の事をいい、排他処理ともいいます。

FileMakerの場合、デフォルトではフィールドの外をクリックしただけでデータが確定（保管）されます。（いいか悪いかは別として・・・）ロールバックはスクリプトなどを仕掛けない限り、元には戻りません。この単純明快さを開発に利用しない手はないと思うのです。
ですが、その単純明快な機能をわざわざ殺し、データを一旦グローバル変数に格納させ、更新させるまではなにもさせず、読み込んだデータが、他のトランザクションによって更新されたかをチェックさせて、ロールバック、コミットさせるSQL手法（楽観法）を用いていたのでは、いったい何のためのFileMakerなのか、そもそも何がしたいのか論に戻ってしまいます。


FileMakerで開発する場合、ユーザーの日常業務、伝票発行等単位ではなく、せいぜい、まとめて行う請求処理中に横入りしてもらいたくない程度のロックくらいか、まとめてデータの置換えが発生するときの制御であれば、ポータルを使って関連レコードをまとめてロックすればいいだけで、毎日の伝票発行毎にロールバックさせるため、わざわざグローバル変数に格納させるスクリプトを作る意味があるのか非常に疑問です。そもそも伝票毎では同レコードを開く事が出来ない作りになっていますからロックを気にすることもありませんし、確定しているんだから、ロールバックじゃなくて書き直せばいい話です。明細１０行確定させず、宙に浮かせ、１０行ロールバックされるほうが迷惑な話という事にもなりかねません。

出来なくはないけれど、FileMakerの性能を下げさせ、めんどくさい非効率開発だと考えます。

これを奨めないFileMakerはRDBMSじゃないとまで云う方もいますが、僕は画期的なRDBMSだと思っています。というより、SQLとは性質が違うと考えるべきかと思います。


障害が発生したときに、更新ログを使って障害発生時までロールバックさせるのではなく、バックアップなどでのロールフォワードを推奨させる考え方、という根本的な考え方の違いもあります。

なんだ、大規模向きじゃないんだ、ではなく、そもそも性質が異なります。

SQLとFileMakerを上手に連携させる事によって明るい希望を持たれるデベロッパーもいます。

いずれにしても開発者事情ばかりではなく、使用者にとって楽で安心、使いやすいものであればいいのだと思います。