『売上猫くん on MySQL』開発日記 - 番外18 - FMで大きなSQLテーブルは扱えるのか？ ― その3

FileMaker のVer9リリース時位にFM社が作成した不思議なドキュメントがある。『Introduction to External SQL Sources』（邦題：外部SQLソース入門）というタイトルが付いており、日本語版と英語版がある。　読んでみると、

ESS 機能セットは、FileMaker Pro をSQL データソースの「フロントエンド」として利用できるようにすることを意図したものではありません。 （The ESS feature set is not intended to allow FileMaker Pro to act as a “front end” to SQL data sources.）

と、衝撃の１文がある。ハァ？　SQLデータベースに接続してFileMakerを使用しようとする者ならだれてもFileMakerまたはFileMakerで作成したアプリ（.fp７）がSQLデータベースのフロントエンドとなる、と思っている筈だ。　試しに「filemaker フロントエンド」をキーにググってみると、そう確信して記事を書いている人がたくさんいることがわかる。ところが、FM社の公式見解は、FileMaker（のESS）は、
「フロントエンド」として利用できるようにすることを意図したものではない、のである。　では、FM社がESSとか呼んでる機能なんなの？、ということである。　小生はフロントエンドとは、「ユーザが操作する部分＝ユーザインタフェイス」位に理解していたのだが、念のためググってみると、こんな感じである。

Wikipedia
フロントエンドは、ユーザーと直接やりとりするソフトウェアシステムの部分を指し、バックエンドはフロントエンドへの出力を生成する部分を指す

IT用語辞典バイナリフロントエンドは、一般的に、表示やデータ入力を行うための仕組みを指し、ユーザーインターフェース（UI）と同義と同義で用いられることも多い。
IT用語時点
ユーザからの操作の受付や画面表示などを担当するGUI(グラフィカルユーザインタフェース)プログラムなどがこれに当たる。

元々の小生の理解と大差は無い。であれば“ESS”はバックエンド（データベース）を操作するためのユーザインタフェイス＝フロントエンドと言ってもいい筈だ。ただのユーザインタフェイスなんだから。　にもかかわらず、「FileMaker はフロントエンドじゃないんだ！」と宣言するFM社の意図はなんなのだろう？

ユーザはこの文章についてどう思っているのかと思いググってみたが、それらしき記事は日本のサイトには見当たらなかった。　海外のサイトには、上記のドキュメントに関する記事・投稿がいくつかある。

参考URL
SQL as backend? （2007年7月、V9当時？）
SQL performance: Alpha Five vs. Filemaker 9 benchmarks （2007年9月）
07.12.07FileMaker 9 SQL Link… ish（2007年9月）
beginners odbc question

特に3つめのURLは、Servoyという開発ツールと比較しながら、FileMakerの問題点を以下のように列挙している。

1. SQLデータ変更時、その変更が他のユーザの画面に反映されない
2. レコードレベルのロック機能がない
3. テーブルやフィールドへの変更が自動的に反映されない
4. ユーザが作成するSQLクエリを発行できない（SQLクエリは全てESSにお任せ）
5. 未サポートのデータ型がある
6. 検索が遅い
7. ソートはさらに遅い（バックエンドでソートを行わず、一旦FMにデータをロードした後にそのデータをソートするため）
8. データベース/テーブルをALTERできない

なんとなく解ってきた気がする。　開発者はFileMakerをフロントエンド開発ツールとして使用し始めると、他ツールと比較していろいろと不便な点があることに気がつく。　特に1.データ型、2.ユーザ独自のSQLクエリが実行不能、よって、3.検索、特にソートが非常に遅くなるというのは大問題で、簡単な回避策は無い。　ところが、多くのフロントエンド開発ツールは、何の問題もなくこれらのことを実行できる。　つまり、FM社が「フロントエンドにはなりませんよ」というのは、「他のフロントエンドツールにできることでも、FileMakerではできないことがあります。　その代り、FileMakerっぽくSQLのデータをある程度なら扱えますよ。　でも、FileMaker純正データベースとは違った結果が返ることも大いにありうるので、そこら辺、凄く注意して使ってね！」というのがかなりホントのところではないかと思われる。

（土屋）





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

『売上猫くん on MySQL』開発日記 - 番外17 - FMで大きなSQLテーブルは扱えるのか？ ― その2

前回の続き

問題4.検索実行時のデータの並び
郵便番号レイアウトの住所で「北海道」を検索すると、MySQL側では以下のようなクエリが走る。

SELECT ID FROM vw_zips WHERE `住所` LIKE '%北海道%'

MySQLは検索対象となったフィールドの文字コード順にデータを返し、それがそのまま表示される(ORDER BY PrimayKey は実行されない)。　この点、FileMakerのデータベースエンジンはテーブル内の並び順（作成順）にデータを返すので、この差異には注意を要す。　尚、その1で書いたように、SQLデータは一旦ロードされると取り込んだ順で保持されるので、プライマリキーにも文字コードにも関係なく、検索結果がぐちゃぐちゃに表示される可能性があることにも注意を要す。


問題5.新規レコード作成時の不審な挙動
a)検索がかかった状態で新規レコードを作成すると、レコードを確定した瞬間にその作成したレコードから新規レコード作成コマンド実行時点で選択されていたレコードに移動してしまう。レコードは作成されているのだが、ブックツールが正しく動作せず、そのままでは作成したレコードに移動できない。　これは単純にバグと思われる。　すぐに気付きそうなものだが、FileMaker社はなぜこのバグを放置したままでいるのだろう？

b)だらだらクエリ---新規レコード作成後のコミット時に、その1で書いた『だらだらクエリ』が走る（レコード数が10万位あると、顕著にだらだら加減が解る）。　我慢できずにエスケープすると、作成したレコードが消失する（FileMaker上でロールバックされる）。


以上で見た問題1～5のようにSQLデータベースの大きなテーブルを扱う際は、レコード（レイアウト）表示、レコード間移動、検索といった基本操作に問題があり、開発者はなんらかの回答を用意しなければならない。　尚、削除、更新については今のところ大きな問題は見当たらない。

問題6　ソートが著しく遅い
FileMaker 側でのソートは著しく遅く、少数のレコードが対象というのでなければ、実用的ではない。　バックエンド側のビューで ORDER BY しておくことは可能だが、解決策とは言えない。


（土屋）

2010/11/05　問題6を追記


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

『売上猫くん on MySQL』開発日記 - 番外16 - FMで大きなSQLテーブルは扱えるのか？ ― その1

MySQLを使用するメリットの一つは、何百万、何千万もの大量のレコードを持つ巨大なテーブルを扱えること。　ところが、そうした巨大テーブルをFileMaker アプリから操作しようとすると、大きな問題にぶつかる。（尚、下記の環境は、クライアントからFileMaker Server上のアプリファイル(NekoApp50.fp7)にアクセスしている。ローカルでNekoApp50.fp7を実行すれば、実行速度は改善される。）

問題1.　だらだらクエリ
例えば、12万件のレコードを持つ郵便番号テーブルをFileMaker のレイアウト上に表示し、一番最後のレコードに移動してみる。移動すると「検索実行中...　　クエリーを処理中」と数十秒またされることになる。これはMySQLのログを見てみるとわかるが、

SELECT DISTINCT ID FROM vw_zips WHERE ID>19 ORDER BY ID
SELECT DISTINCT ID FROM vw_zips WHERE ID>1019 ORDER BY ID
SELECT DISTINCT ID FROM vw_zips WHERE ID>2019 ORDER BY ID
SELECT DISTINCT ID FROM vw_zips WHERE ID>3019 ORDER BY ID
・・・
・・・　中略
・・・
SELECT DISTINCT ID FROM vw_zips WHERE ID>119019 ORDER BY ID

といったクエリをテーブルの全レコード件数（この例では12万件）に達するまで延々と発行し続け、FileMakerにこれまた延々とロードし続ける、という仕様なのである。　実務上、これではユーザから苦情が来るのは必至。　さらに、テーブルデータが100万、1000万件に達する場合は、実用に耐えない。

尚、一度ロードしてしまえば、アプリを閉じるまで、上記の『だらだらクエリ』は実行しないようである。


問題2.　検索を実行すればするほどデータの並びがグチャグチャに？
FileMakerはクエリを実行した順にデータをロードし、一旦ロードされると再ロードは行わない。ユーザの検索実行数が増せば増すほど、レコードは作成順に並ばず、グチャグチャに並んでるように見える。

例えば、郵便番号レイアウトを開くと、FileMakerはそのレイアウトに割り当てられたテーブル（レイアウトテーブル）のレコードの1番目から数十番目までをSELECTする以下のようなクエリを実行し、レイアウト上に表示する（SELECTされるレコード数は、レイアウトの形状、ウインドウの大きさにより異なる）。　

SELECT ID,`〒`,`住所` FROM 郵便番号 WHERE ID IN (1,2,3,4, ～中略～ ,26,27)

次に、ユーザ自ら郵便番号の「9071801」(沖縄県)を検索し、次に「2010004」を検索し、その後レコードメニューから「全レコードを表示」を行うと、以下のような並びになってしまう。


郵便番号「2010004」の後に「0600012」移行が並ぶのは、上記の「全レコード表示」の直後にスクロールダウンした為、SELECT ID,`〒`,`住所` FROM 郵便番号 WHERE ID IN (28,29,～,40,41)というクエリが実行され、該当するレコードがロードされた結果だ。　

FileMaker は内部の SELECTクエリを実行した順にレコードをロードする。　再度検索を行っても、プライマリキーが同じものは再ロードされない。　ユーザが該当件数が少ない検索条件を実行すればする程、レコードは作成順には並ばないため、ユーザからみればグチャグチャに見える。


問題3.　レコード総数取得クエリ
SQLテーブルをレイアウトに最初にロードすると以下のクエリが走る。

SELECT COUNT(*) FROM (SELECT DISTINCT ID FROM vw_salesdtls) COUNTER_TABLE　

この SELECT DISTINCT には時間がかかり、180万件のテーブルだとレイアウトにレコードを表示するだけで30秒程度はかかってしまう（但し、一旦レイアウトテーブルをロードすると、アプリファイルを閉じるまで、このクエリは再発行されない）。巨大なテーブルを扱う場合は、VIEWによりレコード総数を制限する必要がある。


問題3については、数百万レコード程度であれば、ユーザも我慢できるかもしれないが、1と2ついてはなんらかの対応が必要だろう。


土屋　


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