ラベル ODBC の投稿を表示しています。 すべての投稿を表示
ラベル ODBC の投稿を表示しています。 すべての投稿を表示

2017-06-01

MySQL ODBC ドライバインストール時のエラー1918

Windows 2012/2016 にMySQLのODBCドライバ5.3.8をインストールしようとすると、
Error 1918.Error installing ODBC  driver MySQL ODBC 5.3 ANSI Driver...
というエラーが表示される。
対策はVC++ラインタイムをインストールすることだが、Windows のバージョンによって、インストールするバージョンが違うらしい。

Windows Server 2012 の場合→VC++2010ランタイム

Windows Server 2016 の場合→VC++2013ランタイム


参考サイト:


(土屋)

2016-07-06

FileMaker でレスポンシブなWebアプリを作る

 FileMaker(以下、FM)のデータベースを FileMaker Pro 以外のクライアント ― ブラウザ、iPhone/iPad、Android ― でも運用する場合、開発環境をFMにすべきか、カスタムWeb にすべきかを考えると思いますが、その際に考慮べき事項を比較表にまとめてみました。

×: terrible,  △: limited,  〇: OK,  ◎: Excellent
 
Go
WebDirect
Custom Web
開発費用
(Devlopment cost)
×
ライセンス費用
(License cost)
×
×
サーバ機費用
(Server machine cost)
×
×
ライセンス体系
(License policy)
×
×
開発の容易さ
(Ease of development)
×
コードの再利用性
(Code reusability)
×
×
開発の柔軟性
(Development flexibility)
×
×
レスポンシブ性
(Responsive Web Design)
×
×
Android等非iOS機との互換性
(Android compatibility)
×
スケーラビリティ
(Scalabilty)
×
他DBへの移植
(Migration to other DBs)


この表からは、
圧倒的ではないか、カスタムWebは

という感じですが、FMの世界では「開発費用」と「開発の容易さ」が他の要素を圧倒し、Go やWebDirect が採用されやすいのではないでしょうか。逆に言えば、他の要素が重要なプロジェクトでは、FMは使用されないのです。
 
 とは言いいつつ、 FM のカスタムWeb という需要は少なからずあり、またスマホ普及に伴う Mobile First な要望もあり、小社としてもまたーりとそれらにお応えしたい、と愚考している次第です。
 そんなわけで、『FMEasy在庫 IWP/WD R1.5』(以下、FMEasy在庫)をバックエンドに使用し、 iPhone/iPad だけではなく Android 等の非iOS デバイスにも対応したレスポンシブな Webアプリのプロトタイプ開発にトライしていきたいと思います。

開発環境

使用データベース: FileMaker(fmp12)
使用ライブラリ: jQuery、jQuery Mobile
対応デバイス: PC、タブレット、スマホ(非iOSデバイスを含む)


開発方針・目標

第1フェイズ


以下の方向で、FMEasy在庫の出庫関連機能をWebアプリ化→プロトタイプを作成する。
  1. マルチデバイス対応、RWD(Responsive Web Design)採用
    たとえばこんな感じで……。

    【PC利用時】

    Windows Chrome


    【タブレットPC利用時:縦置き】

    Nexus 7, Android, Chrome --- Portrait


    【タブレットPC利用時:横置き】

    Nexus 7, Android, Chrome --- Landscape


    【スマートフォン利用時】

    FreeTel Priori 3, Android, Chrome

  2. XML/fx.php/FM API for PHP/PDO(ODBC)の比較テストを適時実施
     →最適なAPIを決める(努力をする)
  3. 出庫伝票照会機能作成
  4. 出庫伝票追加・更新機能作成
  5. 出庫伝票検索機能及び一覧表示機能作成
  6. 出庫伝票PDF出力機能作成

第2フェイズ

  1. 第1フェイズで作成した機能をライブラリ化
  2. ライブラリを他のDBへ対応させる(PDOなら簡単なんじゃないかな)

第3フェイズ

  1. 上記ライブラリを使用することにより、お客様にレスポンシブなシステムをリーズナブルな価格で提供する
    \(^_^)/

 いろいろ書いてますが、予定は未定ですw


本ブログの関連記事について

 本ブログで今後公開予定の RWD によるカスタムWeb関連の記事は、カスタムWeb による開発を検討されているお客様に小社で開発したプロトタイプの仕様やテスト結果をご覧いただき、プロジェクト検討の一助になることを目指しています。


ということで、次回はこのプロトタイプの照会機能についてご紹介したいと思います。

(亀) 

2016-06-06

API 別/サーバ別FileMaker カスタムWebパフォーマンス比較

 FileMaker で カスタムWeb を構築する場合、どの API が一番高速なのか、と疑問を持たれてきた開発者の方も多いかと思いますが、小社もその一員です><。「FM社がバンドルしてるんだから FileMaker API for PHP なら、まぁ、間違いないだろう」位のノリでそれを採用してしまったりとか。FileMaker API for PHP(以下、FM API for PHP) や FX.php なら、ネット上の情報量も多いですし。
 そんな折、FM API for PHP を使用してWeb システムを構築していたわけですが、JMeter で想定される最大負荷をかけたところ、Web サーバがダウンしてしまうことがありました。 幸い、実運用ではそのような状況には今のところ陥っていないのですが、「これは一度、4つの API で比較テストしておこう」ということになり、今回、その運びとなりました。 また、同テストを FileMaker Server 12 と 15 でも実施しました。以下にその方法と結果を公開いたします。 1ユーザによる郵便番号データの検索と表示という限られたテストなのですが、多少なりとも参考になればウレシイかも、です。

1. テスト方法

全国の郵便番号データを入れた FileMaker データベース(今回は弊社製品『FMEasy在庫』の郵便番号テーブル)を用意し、FileMaker Server 12 と 先月リリースされたばかりの FileMaker Server 15 でそれぞれ公開。
 このデータベースにアクセスして郵便データを検索するための簡単な php ページを作成しました。

 たとえば、FileMaker API for PHP で「北海道」を含む郵便データを検索するときのイメージはこのようになります。

検索実行中!



 そして下図が実行結果となります。
 FileMaker API for PHP による「北海道」郵便データ検索結果は 8242 件(データはかなり古いので、最新のデータでは違う結果が返ると思います)で、このレコードを取得してくるのに 2.9935 秒かかったことがわかります。



2. テスト結果

FileMaker Server 12 と 15 を使用し、それぞれのサーバ上で XML、FileMaker API for PHP、fx.php、POD(ODBC) の 4 種類の API を使って 10 回ずつ「北海道」の検索を実施しました。
 その測定結果は次の通りとなりました。



 FileMaker Server 12 と 15 のバージョン間の比較では、FileMaker Server 15 のパフォーマンスが約30% 良い結果となりました。

 パフォーマンス平均をグラフ化すると、このようになります。

API 別 FMS15 vs FMS 12 パフォーマンス比較


 次に、API の比較ですが、本テストに限っては、PDO が圧倒的に高速でした。北海道に属する全8242レコードの検索・描画の最高速は 0.938秒。 正直、FileMaker の ODBC を介したアクセスは使い物にならない、と過去の経験から思い込んでいたので(その記事がこちら)、この結果は驚きでした(FMさん、御免なさい r( ̄_ ̄;))。 また、2つの php ライブラリでは、FX.php がほんの少し有利で、php ライブラリと 生XML の比較では、生XML が約40% 高速となりました。


 php ライブラリは、Web プログラマにとって扱いやすいというのがメリットですが、処理が関数化されていることによって、その分サーバのパフォーマンスが相当程度犠牲になっているようです。
少ない人数の運用では何ら問題が無かったのに、ユーザ数が増えた途端に業務に支障をきたすようになった、みたいな時は、DBへのクエリやコードの見直しに加えて、XML や PDO への乗り換えも選択肢になるかもしれません。


参考サイト:
FileMaker×PHPで作る、簡単・便利なWebアプリ ― とっても力作なサイト

過去記事:
ODBC ドライバ DataDirect SequeLink を使って FileMaker Pro にアクセスしたときの問題点


(亀)

2011-01-17

『売上猫くん on MySQL』開発日記 - 番外21 - βリリースしまつた

ダウンロード再開しまつた。 MySQL 5.5 に対応させようとしましたが、簡単には修正できなさそう。当面は諦めモード。 ということで、本製品は、現段階では、MySQL 5.5 には非対応!ですので、ご注意ください。 (11/01/21 土屋追記)



最新版のMySQL 5.5で動作しないことが判明したため、一時ダウンロード停止! トホホ…(11/01/20 土屋追記)



ようやく「売上猫くん on MySQL 5.0」のβ版(フリーウェア)をリリースすることになりました。
売上明細のテーブルに200万程度のレコードを入れてテストを行っています。
現時点でできるかぎりの巨大テーブル対応と、ストアドプロシジャやトリガを使用した高速化を行っています。 200万行のテーブルがあっても、起動が若干遅いこと、起動後最初に売上明細テーブルにアクセスにいくと10秒位コーヒーマークがでる位で、使用できるレベルではないか、と思ってます。 1000万件クラスのテーブルになると、今以上の対策がいるかも知れないです。

ご興味のある方は下記からダウンロードしてくださいね。 

売上猫くん on MySQL 5.0βのサイト
http://www.tpc.jp/product/neko/50/index.htm

ダウンロードページ


尚、バージョンを 5.0 としているのは、FileMaker Pro 5/6 で作成した旧製品「売上猫くん 4.5」の機能のほとんどを継承しているからです。データベース(バックエンド)に MySQL を使用した猫くん製品は、これが最初となります。


2010-11-16

『売上猫くん on MySQL』開発日記 - 番外20 - ウィンドウ内容の再表示ステップ実行時のクエリ

SQLデータベースを使用時、あるユーザが行った更新は他のユーザの画面に即時反映されることは無い。他のユーザが更新を行ったか否かを確認するには、[ウィンドウ内容の再表示]ステップを使用するが、このステップには、「キャッシュ結合結果を書き込む」「キャッシュされたSQLデータ」という2つのオプションがある。 オプションによって、SQLデータベースに送られるクエリにはどういう違いがあるのか?

1.キャッシュ結合結果を書き込む/キャッシュされたSQLデータの両オプション選択時
SELECT ID,`〒`,`住所` FROM vw_zips WHERE ID IN(121013,121014,~) 等のクエリを発行、画面は更新される

2.キャッシュ結合結果を書き込のみ
クエリ実行されず、画面未更新

3.キャッシュされたSQLデータのみ
上記1と同様

4.オプション無
クエリ実行されず、画面未更新

FileMakerの[レコード]-[ウィンドウ内容の再表示]を実行すると、1と同じ結果となり、画面は更新される。


注:
  • Selectクエリの対象となるフィールドは、レイアウトテーブルの全フィールドと、そのレイアウト上の関連フィールドに限られる。 よって、関連フィールドの値を最新に更新したい場合は、そのフィールドをレイアウト上に明示的に配置しなければなならい点に要注意。
  • 他ユーザが追加したレコードについては、[ウィンドウ内容の再表示]ステップでは表示できない。追加されたレコードをSelcectするような検索を実行すること。
参考URL
http://www.filemaker.co.jp/help/html/scripts_ref2.37.9.html


2010-11-08

Windows 2008 R2 64 ビットで 32 ビット用の ODBC ドライバを動かす

 Windows Server 2008 R2 64 ビット環境で 32 ビット版用に開発された ODBC アプリケーション(例:FileMaker Server 11) は、通常の ODBC データソースアドミニストレーターからは参照することも使用することもできません。

 32 ビット用の ODBC データソースアドミニストレーターは以下のディレクトリに配置されています。

C:\Windows\SysWOW64\odbcad32.exe

たとえば、接続先のアプリケーションが 32 bit 版にしか対応していない場合は、odbcad32.exe を使用して ODBC 接続設定を行います。

2010-11-05

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

前回は、FM社製のドキュメント(日本語版英語版)内の一文を引用し、それを小生なり解釈すると「他のフロントエンド開発ツールに比べるとFileMakerのESSはかなり限定されていること、また一見してFileMaker単体のシステムと同じ結果を返すように見えても異なることがある。ユーザはESSの限界と特性を意識して使用すべし」となる旨のことを書いた。これに加えて、同ドキュメントにもう一つ気になる文章がある。
    ESS は、FileMaker Pro ソリューションを、FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる手段として設計されたものではありません。(ESS is not designed as a means to allow a FileMaker Pro solution to scale beyond the limits of a purely FileMaker Pro based solution.)
この一文は何のことを言っているのか? この日記番外シリーズにも書いたように、FileMakerソリューションであっても、当然ながら、SQLデータベースの多くの機能---ビュー、ストアドプロシジャ、トリガ、ログ照会、バイナリ/トランザクションログからのリカバリ等----FileMaker純正データベースエンジンでは不可能だった機能の恩恵に浴せる。この場合、主語を“ESS”ではなく“FileMaker”にすれば、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップできる」のである。

とするとこの文は、「FileMaker純正データベースエンジンが実用的には(“論理的”にではない)取り扱うことができない大きなテーブルをSQLデータベースのそれに置き換えても、やはり実用的には取り扱うことはできない」と言っているのだと思われる。 タイトルにある「 FMで大きなSQLテーブルは扱えるのか?」という命題への直接否定のようだ。

直接否定だとすると、FileMakerの理論上、仕様上の限界はデータベース単位で8TBであるが、実用上の“限界”はどのくらいなのだろう? 古い記事だが、「(個人的な意見だがテーブルベースで)100万を超える位なら大丈夫だよ」とある。 小社でも数十フィールドあるFileMakerテーブルに100万~200万弱のレコードを収納して数年間、運用している。 200万レコード程度をFileMakerの“限界”と仮定すると、その“限界”を超えて、と主張するには、レコード件数的には400万レコード以上をテスト時の最大数とすれば十分だろうか。ちなみに、『売上猫くん on MySQL』のテスト環境で、いまのところ一番大きなテーブルのレコード数は約180万件である。

ただレコード件数をいくら増やそうとも、ユーザが強いストレスを感じたり、安定性が無いシステムでは“実用的”とは言えない。 “実用的”と言うには、その1とその2で書いたような問題をできる限り顕在化させてはいけない。問題6の激遅ソートは回避策がないので、ユーザによるカスタムソートの実用性は非常に低い。 その他の問題については、回避策を施したり、 運用で調整する(例えば、.fp7ファイルをサーバ上に置かず、ローカルに置く)ことにより、緩和できるものと判断している。 だが結局、「FileMaker Pro のみをベースにしたソリューションの限界を超えてスケールアップでき」たかどうかというのは、公正なエンドユーザの判断に拠る、としかいいようがない。

(土屋)

注:
「~限界を超えて~」については、上記の英文をキーにググってみたが(その3の参考URLを参照)、2007年当時は否定的な見方が優勢だった。 2008年以降は関連する記事を見つけることができなかった。


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

2010-11-04

『売上猫くん 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.)

と、衝撃の1文がある。ハァ? SQLデータベースに接続してFileMakerを使用しようとする者ならだれてもFileMakerまたはFileMakerで作成したアプリ(.fp7)が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』開発日記の記事一覧

2010-10-26

『売上猫くん 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』開発日記の記事一覧

2010-10-21

『売上猫くん 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』開発日記の記事一覧

2010-03-31

『売上猫くん on MySQL』開発日記 - 番外8 - insert...select構文とODBC

以下、ODBC 5.1.5だと×、5.1.6だとOK

INSERT INTO estimates(customerNo) SELECT customerNo FROM estimates WHERE ID=5

これ、痛い。 この構文使えずに困っている人、結構いるんじゃなかろうか? 回避方法も見つからないし。


参考サイト:Bug #42905


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