前回の続き
問題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』開発日記の記事一覧
0 件のコメント:
コメントを投稿