SQL関連記事と『売上猫くん on MySQL』開発日記の一覧

---

【FileMaker/MySQL環境での大容量データ取扱（英語のみ/動画による実例あり）】
Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one
FileMaker vs Access 実行速度比較検証


【FMEasy在庫 on MySQL関連】
『FMEasy在庫』 のバックエンドを MySQL に変える (1) ― 概要
『FMEasy在庫』 のバックエンドを MySQL に変える (2) ― 在庫1
 

【その他のFileMaker/MySQL関連】
 ファイル起動時にFileMakerからMySQLに投げられるクエリ



【MySQL Workbench関連】
MySQL Workbench の EER モデリングツールでリレーションシップ検証 1 （Identifying と Non identifying）
MySQL Workbench の EER モデリングツールでリレーションシップ検証 2 （外部キー制約の種類と動作）
MySQL Workbench の EER モデリングツールでリレーションシップ検証 3 （リレーションシップアイコンの種類と使い方）
 


【売上猫くん開発日記 ― 番外編】
番外1 -全データベース削除→リストア
番外2 - MySQLミラーサイト
番外3 - 0を書き込みできない
番外4 - mysqldump で文字化け？
番外5 - ポータルで検索できない
番外6 - リモートのログを mysqlbinlog できない
番外7 - FileMaker内にMySQLの一般ログを表示する
番外8 - insert...select構文とODBC
番外9 - 外部キー制約設定でのたうちまわる
番外10 - 開発再開
番外11 - 外部キー ってさぁ…　orz
番外12 - トリガの制約
番外13 - MySQL Workbenchの憂鬱（ほぼ私的メモ）
番外14 - テーブル毎に権限を設定する（ほぼ私的メモ）
番外15 - 再び権限（私的メモ）
番外16 - FMで大きなSQLテーブルは扱えるのか？ ― その1
番外17 - FMで大きなSQLテーブルは扱えるのか？ ― その2
番外18 - FMで大きなSQLテーブルは扱えるのか？ ― その3
番外19 - FMで大きなSQLテーブルは扱えるのか？ ― その4
番外20 - ウィンドウ内容の再表示ステップ実行時のクエリ
番外21 - βリリースしまつた
番外22 -SQL SECURITY の DEFINER/INVOKER指定
番外23 - FileMaker vs Access ～　実行速度編　～
番外24 - MySQL 5.5は使用できるのか？
番外25 - 行ロックについて


【売上猫くん開発日記 ― 本篇】（←メインになる筈が、見捨てられた哀れな本編）
1 (題目無)
2 - 開発環境
3 - FMからストアド、トリガ

『売上猫くん on MySQL』開発日記 - 番外24 - MySQL 5.5は使用できるのか？

FileMakerとMySQL 5.0/5.1で開発してきた人へ：

『売上猫くん on MySQL R5.0β』は、FileMaker 11（FM11）/MySQL 5.1で開発した。　そのDBダンプをMySQL5.5上 にリストアして、FM11フロントエンド（NekoApp.fp7）からアクセスしようとすると、以下のような状況となり、アクセスできない。

このNekoApp.fp7をFileMaker 12（FM12）でNekoApp.fmp12に変換し、MySQL5.5にアクセスするとどうか？

と、さらに悲惨なこととなる。

NekoApp.fp7のリレーションシップ画面を開いてみると、下図のように一見すると正しくテーブルは認識されているようだが、TOをダブルクリックしてみるとTOとテーブルのリンクが消失していて、テーブルを指定し直す必要がある。

また、その指定し直しの過程でリレーションシップが飛んでしまったりもする。　TOとリレーションシップをすべて再設定・確認するだけども大変な作業になるし、検証作業も含めると…　膨大な作業になる。

注：

• 使用しているODBCのバージョンは、5.1.11。 
• FM社が公式サポートするMySQLは現時点でMy SQL 5.1 Community Editionのみ。
• MySQL5.1を介さず、最初からFM11/12とMySQL5.5でリレーションシップ（TO）を作成しておけば、とりあえずは動作するようである（要検証）。

（土屋）


関連リンク：『売上猫くん on MySQL』開発日記の記事一覧

簡単？ FileMakerで在庫管理（２） ―― 繰越処理の考え方

　今回は、繰越処理に伴う在庫算出について考えていきましょう。　在庫算出の基本については、以下の記事をご覧ください。

　簡単？　FileMakerで在庫管理（1） ―― 在庫算出の基本

繰越処理の考え方

　入出庫のレコードが増えてくると、在庫算出時に合計する入出庫明細レコードが膨大になり、処理速度が低下します。
　そこで、在庫数の繰越処理を行うことによって、在庫算出処理を行うことにより、在庫数算出を高速化する必要があります。
　
　たとえば、商品Aの2011年6月～2012年5月の入出庫明細データが10万件あったとします。
　2012年5月31日時点の商品Aの在庫を算出しようとして、入出庫明細レコードを10万件を対象に、Sum(入庫明細::入庫数)-Sum（出庫明細::出庫数） をやっていては、処理時間が膨大になってしまいますが、繰越処理を実行することによって2012年4月末時点の商品Aの在庫数を商品テーブルに保管しておき、5月1日～5/31の入出庫明細レコードのみをSumの対象となるようにリレーションを組めば、Sumの対象となるデータは、単純試算では10分の1以下となります。

　次に在庫算出の計算式を、以下のように繰越処理を行った場合と、行ってない場合とでは、在庫算出の計算式が違ってきます。

A式： 導入時在庫数+（4/25以前の入庫計）-（4/25以前の出庫計）

B式：　繰越処理日≦在庫基準日の場合の在庫算出式
繰越在庫数+（4/1～4/25の入庫計)-（4/1～4/25の出庫計)

C式：　繰越処理日＜在庫基準日の場合の在庫算出式
　　導入時在庫数+（2/28以前の入庫計）-（2/28以前の出庫計）

　要はA、B、Cの式をCase分けして、ひとつにまとめる必要があるわけです。

繰越処理と制御

　さて、繰越処理で考えておかなければいけない重要なことが一つあります。それは、繰越処理日（上記例では3/31）以前のデータ、在庫に関していえば、3/31以前の入出庫レコードの出庫日と入庫日、出庫数と入庫数を変更不可にしておく必要があります。また、3/31以前の同レコードは削除させてはならないし、繰越処理日以前の入出庫日を持つ同レコードは作成させてもいけません。　

　その理由は、［繰越在庫数］との整合性がなくなってしまうからです。

やがて訪れるデータ削除の時期について：
　長期間使用するシステムでは、繰越処理を行ってもレコードはどんどん蓄積されていきます。当社が開発・保守を担うシステムでは百数十万件の入出明細データを持つテーブルがありますが、ほぼ定期的にデータ削除を行っています。小社では、FileMaker のテーブルの最大レコード蓄積数は200～300百万件を一つの目安としていますが、データの削除は、システム仕様、実行速度要求、保持データ数要求、バックアップポリシー等の諸事情を勘案し、システムが安定動作することを大前提に実行してください。一般ユーザがデータ削除を行う場合は、一括データ削除機能も必要になります。
　また、削除したデータを照会したい、といった要望も必ずといっていいほどユーザより提示されるので、できれば過去データの照会についても予め考慮してシステム設計を行います。

在庫管理は簡単か？

　残念ながら答えは NO です。
　システム的には、繰越処理とそれに伴う伝票制御、旧データ削除時の処理を考慮せざるを得ず、在庫管理システムを作るのはやはり簡単ではない、というのが結論になります。

　また、繰越処理関連を適正に実装できたとしても、1カ月に同一商品の取引が数百回以上あるような業務では在庫算出処理の遅延も予想され、別の在庫算出手法（拙稿の「FileMaker V10による在庫管理、一考」の1、2、3を参照）の採用も選択肢に入れなければならないでしょう。

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

土屋