シリアルNOの初期値化と欠番

いろんな局面でシリアルコードが使われていますが
特に入力と明細など親子関係を持つ伝票NOや、病院などの外来で日によって詳細が増えるもの、弁護士さんなら案件Noなどが対象かと思うのですが、コード番号をKeyにしてデータベースを処理される事が多いかと思います。
（顧客マスタや商品マスタなど、日々増えるものでなければデフォルトのオプションで十分）


レコードを増やせば001+１（増分）

はオプションで設定できますが、翌日は001から始めたい
などの場合は自己リレーションと計算式を用いれば可能になります。

これは日付で初期化し、001から始める方法ですが、月によって001にしたり桁を増やして0001にしたりも出来ます。コード番号が整理されて帳票なんかも見やすくなります。

サンプルがダウンロードできますので見ていただければ分かるのですが、

シリアルコードを作るのに、それに関係するフィールドが増えちゃうのが難点でもありますが、覚えて損はないかと思います。デフォルト装備のオプション設定では、001に戻すために都度、管理者権限のデータベースの管理でオプションを変更する、なんて面倒な事したくないですし・・・。

日や月によって001に戻ってくれたり、レコードを全部削除しても、新規レコードで001から始まってくれるのは便利です。

＜欠番＞

しかし、このコード、親子関係にあればKey設定をしますので、レコードを削除した時に欠番をどうするか考えなくてはいけません。

今回は欠番が発生したらそのままにする方法と欠番以降を詰めて連番にさせてしまう方法の2種類をサンプルにしました。

いろんなサイトでシリアルについての注釈が掲載されていますが、僕的には欠番を詰めて連番にさせる方法は好ましくないと考えています。

リレーションで親子関係にあれば、欠番が詰まって連番化されたことで、子の側のデータもズレて（書き換わる）しまうからです。これでは整合性が保てません。ですので、レコードを削除して欠番が発生したときは、そのまま放置をお奨めします。

では、欠番なしとは、どういうケースで使用するか、ですが
伝票などのトランザクション（親子関係）ではなく、呼び出しだけに使用するマスタ等であれば、Noを詰めても良いと考えます。ただし、商品マスタなど後に商品別の分析をするのであれば、危険です。担当者や人事などでも定年や退職などで欠番が出ますが、欠番なしになると欠番以降の関連データが飛んでしまいます。

僕の場合は、欠番なしという手法で開発を手掛けたことはありません。





ダウンロード（FM13以上）

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を上手に連携させる事によって明るい希望を持たれるデベロッパーもいます。

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