Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one

The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:

Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.

1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.

	Common Model	BTHM	Remarks
Fast development	Yes	No
Ease of operation	Good	No so good
Performance for big tables	Very poor	Good
Weird behaviors	Many	Minimum
Records order	Weird	OK	Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya

『FMEasy在庫』 のバックエンドを MySQL に変える（２） ― 在庫

　本稿では、リリース予定の『FMEasy在庫 on MySQL R1.5』（仮称）の商品画面の在庫に関して説明いたします。

　以下が商品画面となります。

　『FMEasy在庫 on MySQL R1.5』では、2つの方法で在庫を算出します。
　一つは「SQL Update方式」、もう一つは「FM計算方式」です。

　それではそれぞれに関して説明します。

SQL Update方式

※特徴
　この方式は“実行”ボタンをクリックすることにより、［在庫基準日］時点の全商品の在庫数を算出して記録します（技術仕様的には、入庫数計/出庫数計/在庫数を「upd在庫」という専用テーブルに記録します）。

　一旦記録されたデータは次に“実行”ボタンを実行するまで更新されません。
したがって、“実行”ボタンクリック時点には最新情報ですが、時間が経過するに従い、最新の在庫数とは異なる可能性が高くなります。

　“実行”ボタンクリック時に入出庫データが大量にある場合、処理に数秒～数十秒、1千万件を超えるような場合は数分かかる可能性がありますが、処理が終了してしまえば即座に数値を表示・印刷できます。
　「SQL Update方式」は、在庫表などで在庫情報をリスト形式で表示・印刷する場合、高速に処理することができます。

注：
　本機能はクライアント/サーバ環境に置いて、FileMaker ServerにODBC設定がされていれば、FileMakerクライアントにはODBCのインストール/設定は不要です。

※操作方法
　実行ボタン　―　任意の［在庫基準日］を指定して本ボタンを実行すると、［在庫基準日］時点の入庫数/出庫数/在庫数が算出・記録されます。

　当方のクライアント/サーバ環境下で、入出明細レコード170万件に対してこの処理を実行すると、30秒～1分程度の時間を要します。

　作成済在庫データ選択ウインドウ（FileMaker 13使用時のみ）　―　実行ボタン右横の黄色の部分をクリックすると、小さなウインドウ（下図）が表示されます。この時、プルダウンメニューをクリックすると、他のユーザ（アカウント）が作成した在庫データの一覧が表示されるので、ここでその内の一つを選択すると、以後、「SQL Update方式」には選択したアカウントが作成した在庫データが表示されます。

他のアカウント(admin/seminar/stockchecker)が作成した在庫データを照会できる。
アカウント右側の日付は、データ作成時に指定した［在庫基準日］

注：
　各ユーザ（アカウント）は［在庫基準日］を指定して“更新”ボタンを実行することにより、全商品の在庫データを作成・記録できます。
同アカウントが次に“更新”ボタンを実行すると、前回作成した在庫データは上書きされます。例えば、admin アカウント で［在庫基準日］に「2014/11/27」と指定して本ボタンを実行すると、全商品に対して［在庫基準日］時点の在庫データが作成されますが、次に adminアカウントが「2015/12/31」を指定して同操作を実行すると、「2014/11/27」時点のデータは上書きされます。

　尚、他のアカウントが作成した在庫データは上述の通り照会することはできますが、別のアカウントで上書きすることはできません。例えば、adminアカウントでログインしている場合、seminar が作成した在庫データの照会はできても、上書きすることはできません。

FM計算方式

※特徴
　この方式は旧来のFileMakerの計算式を使用した在庫算出方法（参考記事）です。この方法のメリットは、常時最新の在庫情報を表示される点です（下記注参照）。

　ディメリットは、入出庫明細にデータが多量にある場合、在庫情報の表示に時間がかかることがある点です。 例えば、入出明細レコードが170万件あり商品Aを含むレコードがその中に2万9千件ある場合、当方の低SPECなクライアント/サーバ環境下では商品Aの［在庫数］を算出するのに5秒強程かかります。

　商品画面で個々の商品情報を一つ一つ計算・表示する場合はまだいいのですが、複数の商品の［在庫数］をリスト形式で表示する場合はかなりのストレスを感じます。

注：
　ネットワーク上の他ユーザが照会中の商品の入出庫データを追加・更新した場合、“画面更新”をクリックすると、最新の在庫情報が表示されます。

※操作方法
　計算するチェックボックス　―　チェックすると「FM計算方式」の在庫情報が表示されます。チェックを外すと在庫情報の計算を行わないので、画面表示が高速になります。

　尚、「FM計算方式」の出庫数計/入庫数計/在庫数のフィールドをレイアウト上に配置するだけで、システム起動後に初めて商品レイアウトを開く際に時間がかかります。
入出明細に170万件のレコードがある場合、当方の環境下では、1分前後の時間を要します。

　この詳しい理由については割愛しますが、簡単に言うと入出明細テーブルのビューに対して、DISTINCT句を含むクエリを発するためです。
「FM計算方式」が不要であればこれらの3フィールドはレイアウト上から削除して構いません。

　その他の在庫関連記事を読む

以上

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成

　前回の記事では、iPad のバーコード読み取りによる棚卸入力機能を実装するところまでをご紹介しました。

　『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

　棚卸作業をしてみると、システム上の在庫数と、棚卸在庫数（実在庫）が一致しない　―　誤差がでる ― ことはよくあることです。

FMEasy在庫 R1.0/R1.5 に在庫誤差調整伝票作成機能を実装する

　今回は『FMEasy在庫 R1.0/R1.5』をカスタマイズし、入庫/出庫の調整伝票を作成することにより在庫誤差調整を行う機能の作成方法をご説明します。

　前回と同様、以下の用語を使っていきます。

【用語解説】

在庫数　―　システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の［在庫数］。以下の［棚卸在庫］とは異なる可能性がある

棚卸在庫　―　実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数（=［在庫数］）とは異なる可能性がある

棚卸　―　 実際に存在する商品の数を（カスタマイズ後の）『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整　―　 「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

　それでは、こちらの動画をご覧いただいたあとで、実際のカスタマイズ方法をご紹介します。

【開発レベル】
中級（レイアウト修正、テーブル修正、スクリプト修正について理解している）

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。

注意：
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 在庫誤差調整に必要なフィールドを準備

　以下のフィールドを EasyData15.fmp12（R1.0の場合、EasyData.fmp12） の商品テーブルに追加します。

　[c在庫誤差]（計算）　―　在庫誤差、誤差がある場合、調整の対象となる
　式：　If(棚卸在庫 = ""; 0; c在庫数 - 棚卸在庫)   //[棚卸在庫]が空欄(未入力)の場合、誤差は 無いものとみなす

　[c入庫数調整]（計算）　―　[c在庫誤差] がマイナスのときに、この誤差を入庫対象数とする
　式：　If(c在庫誤差  <  0; Abs(c在庫誤差); 0)

　[c出庫数調整]（計算）　―　[c在庫誤差] がプラスのときに、この誤差を出庫調整伝票の対象とする
　式：　If(c在庫誤差  > 0; c在庫誤差; 0)

　[gNo]（数値型、グローバル）　―　入庫伝票No/出庫伝票No の入出明細取込用一時記憶フィールド、後述のスクリプトで使用

2. 在庫誤差調整伝票作成スクリプトを作成

　このスクリプトの仕様は以下の通りです。

1)  在庫基準日を本日の日付（棚卸作業実施日）にする。
2)  棚卸作業を行わなかった商品は調整対象から除外する。
3) [在庫数] - [棚卸在庫] の誤差がプラスの場合は 出庫伝票、マイナスの場合は 入庫伝票 を作成する。
4) [在庫数] - [棚卸在庫] が 0 になる商品については、調整伝票を作成しない。
5) 入庫伝票/出庫伝票 の[伝票区分]は [7:在庫調整]（新設）とし、通常の伝票区分とは区別する。
6) 入出明細::備考フィールドに[棚卸担当ID]を記録。

　上記の条件に従ってスクリプトを記述すると、たとえばこのようになります。

　スクリプトの流れ上、入力チェックやウィンドウ切替などのステップも含まれていますが、基本的には上記の赤囲みの部分が押さえられていれば調整伝票を作成できるようになります。

① システム在庫を本日時点のものにする

　棚卸作業が終わった直後、つまり本日時点のシステム在庫と、棚卸在庫の差違をみるため、[在庫基準日1]　に本日の日付を設定します（Get(日付)）。

② [c入庫数調整] に値が入っている商品データを検索します。　
　このデータが入庫伝票作成対象となります。
　対象レコードがみつかった場合は、入庫伝票を新規作成し、その[入庫No]を [gNo]に一時記録します。

　次に、対象商品データを入庫明細として「入出明細」テーブルに取り込みます。
　その際、[入庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
仕入単価	→	仕入単価
JAN	→	JAN
棚卸担当ID	→	備考
c入庫数調整	→	入庫数量
gNo	→	入庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

③[c出庫数調整] に値が入っている商品データを検索します。　
　このデータが出庫伝票作成対象となります。
　対象レコードがみつかった場合は、出庫伝票を新規作成し、その[出庫No]を [gNo]に一時記録します。

　次に、対象商品データを出庫明細として「入出明細」テーブルに取り込みます。
　その際、[出庫No] として[gNo]を取り込みます。
　取り込み順は以下のとおりです。

(商品テーブル)	→	（入出明細テーブル）
商品ID	→	商品 ID
g在庫基準日1	→	入出庫日
単位	→	単位
販売単価	→	販売単価
JAN	→	JAN
棚卸担当ID	→	備考
c出庫数調整	→	出庫数量
gNo	→	出庫No

　※データ取り込みのデータ自動入力オプションはオンにします。

　ここまでできたら、一度スクリプトを実行してみましょう。
　調整伝票が作成されるとともに、商品の[在庫数]と[棚卸在庫]がぴったり一致していれば成功です。

【入庫調整伝票の例】

【出庫調整伝票の例】

【在庫の一致を確認（テスト段階）】

　何度かテスト実行して、問題がなければ、上記スクリプト内でコメントアウトされている[棚卸在庫]および[棚卸担当ID]の全置換クリアステップを有効にします。

　これにより、棚卸調整在庫が作成された後は、自動的に棚卸情報がクリアされますので、次回の棚卸作業時に[棚卸在庫]および[棚卸担当ID]フィールドがクリアされていないということがなくなります。

【在庫誤差調整伝票スクリプトの配置場所】

　在庫誤差調整伝票作成の実行ボタンは、ここでは商品一覧画面に配置してみます。
　赤囲みのところにご注目ください。
　[棚卸在庫]フィールドを[在庫数]フィールドの下に配置することで、調整伝票作成前に棚卸状況を確認できるようになっています。

　そして、“調整実行”ボタンをフッタ位置に配置し、ボタンクリックで調整伝票を一括作成することができます。

　“調整実行”ボタンについては、ユーザ権限による制御を追加するなど、誤操作防止策を検討してみてください。


【重要：在庫誤差調整伝票を作成するタイミング】

　システム在庫は常に変動しています。
　このため、棚卸作業開始～在庫誤差調整伝票作成完了までの間、一般ユーザによるシステムの使用や入出庫作業を禁止する必要があります。

　「禁止！」と言っているのにアクセスしてくる困ったちゃんがいる場合、FileMaker Server を停止し、サーバ上で本スクリプトを実行します。
　これにより、在庫の誤差がなくなることになります。

　なお、繰越処理（在庫や各種残高を繰り越す処理）を行っている場合、繰越処理の中に本スクリプトを組み込むのも Good！と思います。

　その他の在庫関連記事を読む

（亀）