現在Delphi2007とAccess2007を使用して新しいシステムのために調査をしています。
どれくらいのスピードが出るかが一番気になるのでテストしてみました。
郵政省の郵便番号CSVをデータベースに変換してみました。
CSV -> DBiSAM 1分53秒
CSV -> Access2007 5分57秒
Access2007へは「Microsoft Office 12.0 Access Database Engine OLE DB Provider」を使っています。
ちなみにODBCでやってみると7分17秒もかかりました。
Access2000はDBiSAMより早いとぽんぽんさんの検証結果が載っていましたが、Access2007は検証結果で見るとちょっと使いたくないパフォーマンスです。
Access2007使われている方はいますか?
いつもお世話になっています。
私も先日、QuickReport の解決に伴い、D7 および BDE/Paradox を
断念しました。現在の環境は、WinVista + D2007 です。
データベースへの接続は、
D2007 の dbGO の TADOTable/TADOQuery を使用し、
ConnectionStringにMicrosoft Jet 4.0 OLE DB Providerを指定しています。
対象の D/B は、MS-Access2007 を使用していますが、あえて保存形式を
Microsoft Office Access データベース(2002-2003 形式)(*.mdb) にしています。
※当面の互換性を考慮し、(*.accdb) 形式にはしていません。
というより*.accdb はテストもしていないので使用できるのかも不明です。
BDE/Paradox を使用した変更前のアプリと比較すると、あくまで個人的な
体感ですが、ADOTable1.Open; または ADOQuery1.Open; と指定した直後の D/B への接続には BDE/Paradox と比較してかなりの時間がかかっているよ
うです。しかし、その後の連続読み出しとか追加書き込みに於いては遅い
という感覚はありません。
※プログラムの構造上、連続更新処理はしていません。
全件の連続削除処理を実行し、その後連続追加処理をしているので。
BDE/Paradox を止めた直後は、確かにユーザーから遅くなったとの苦情が
多くよせられました。
ADOTable1.Open; または ADOQuery1.Open; の実行タイミングを見直し、Open したらまとめてデータ処理するよう最適化?することにより、現在は
遅いという苦情はなくなりました。むしろ最適化?の効果もあり、以前より
速くなりました。
以上、ご参考まで。
※(*.mdb) を使用しているので、Access2007 を使用している事にはならな
いですね。ごめんなさい。これを機会に (*.accdb) もテストしてみます。
こんばんは。
スレッド主さんの内容からは外れますが、
めるめるさんのおっしゃっている「QuickReport の解決」とは
どのようなことなのでしょうか?
「QuickReportの不具合が、バージョンアップによって解決した」
ということなのでしょうか、それとも
「いま制作しているアプリケーションが QuickReportでプログラムできた」
ということなのでしょうか。
帳票出力の「QuickReport」の最新情報が気になりますので、
教えて下さい。
いつもお世話になります。
> QuickReport の解決に伴い...
D2007 の発売当時、D2007対応のQuickReportが存在しなかったため、
やむを得ず D7 を使い続けていました。
その後、D2007 対応の QuickReport4Pro(4.0.7) が発売になり、無事
D2007 に移行できたということです。
※けっして QuickReport バグが無くなったとかいうレベルではありません。
過去の資産(遺産?)である、
Win2000/XP + D7 + QuickReport(3.0.9) + BDE/Paradpx のアプリが、
WinVISTA + D2007 + QuickReport4Pro(4.0.7) + Jet4.0/mdb で無事稼働
できました。
めるめるさん、回答ありがとうございます!
> ※けっして QuickReport バグが無くなったとかいうレベルではありません
やっぱり(涙)QuickReportのバグは無くならなかったんですね。。。
帳票出力は、D1にはなかったので、D3の時に付属していてとても嬉しかった
のですが、次に買ったD6は残念な結果でした。
んー。
お久しぶりでございます。
ジュウザさん、検索の速さはいかがでしょうか?
もしできましたら、お知らせくださるととても勉強になります。
私くし事ですが、未だにDBMSを何にするか悩んでいます・・・。
現在、SQLiteの実験をしようと思います。
自分自身、とても期待しているDBMSです。
別の仕事が発生して検証がなかなかできずにいます。m(__)m
とりあえずaccdbが遅いのかと思い、Access2007で2002-2003互換形式のmdbも検証してみました。
テストは同じ郵便番号の書き込みです。
今回の結果は、
CSV -> Access2007(accdb) 5分53秒 Office 12.0 Access Database Engine
CSV -> Access2007(mdb) 5分59秒 Microsoft Jet 4.0 OLE DB Provider
6秒差はありますが、膨大な件数考えたら誤差範囲ってとこでしょうか。
ぽんぽんさん、検索は時間ができたら検証してみますのでしばらくお待ち下さい。
まったく気になさらないでください。
仕事が忙しいのかな?と、お察ししておりましたから、すでに了解しております!
ようやく別の仕事が終わり、中断していた検証を再開できました。
とりあえず今回の結果を載せておきます。
書き込みは前回同様、郵便番号データCSVからの変換です。
読み込みは上記で出来たデータを単にFirstして最後までNextです。
検索はそのデータから1件のデータをSQLで取得し、条件を変更して900件ほど繰り返しました。
< 書き込みテスト >
CSV -> DBISAM 32秒
CSV -> Access2007 5分26秒 Office 12.0 Access Database Engine
CSV -> Access2007 5分23秒 Access2003互換mdb Microsoft Jet 4.0 OLE DB Provider
< 読み込みテスト >
Read DBISAM 7秒
Read Access2007 2分53秒 Office 12.0 Access Database Engine
Read Access2007 2分58秒 Access2003互換mdb Microsoft Jet 4.0 OLE DB Provider
< 検索テスト >
SQL SELECT DBISAM 20秒
FindKey DBISAM 0.16秒
SQL SELECT Access2007 3秒 Office 12.0 Access Database Engine
SQL SELECT Access2007 2秒 Access2003互換mdb Microsoft Jet 4.0 OLE DB Provider
やはりAccessは遅くなりますね。
検索ではSQLだとDBISAMが負けていますが、DBISAMだとFindKeyが使えるのでそれだと一瞬です。
とりあえずDBISAMのメーカーに再度Vista対応についての質問をしておきました。
しかし数週間前にホームページから問い合わせたんですけど回答なかったんですよねー
今回は回答あるかな?
ジュウザさん、検証ありがとうございます!
「検索」と「読み書き連続」だと、こんなにも変わるのですね。
オールマイティでないのですね・・・残念です。
色々な条件に見合う、DBMS選びは難しいですね・・・不安な気分ですが、小生、頑張って選んで行きます!
DBISAMメーカーから返事が今月始めにありました。
おおまかにまとめますと、
まず、DBISAMの新版である ElevateDBは2月に出荷され、すでにマイナーバージョンアップを5回済ませてVer.1.05になっており、弊社はこれを仕入れて販売することが契約上は可能な状態です。
あとは、動作検証とWebサイト・マニュアルなどの(一部でも)日本語コンテンツ作成ですが、正直に申し上げると、採算ベースには乗らないボランティア的作業ですが、お客様のリクエストがある以上、やります!!
という事です。
興味ある方は鉄飛さんに詳しい事を聞いてみて下さい。
書き込みが遅くなったのは今月始めに上層部から呼び出しがあり、簡単に表現すると「今年に完成させろ!」との事になりました。
直属上司からはそんな緊迫した状況とは聞いてなかったため、Vista正式対応のDBMS調査をしていたんですが、そんな状況ではなくなりました。
そのためここへの書き込みも遅くなってしまいました。
人材も4人チームだったのが私だけになり、急遽完成に向けてのステップに入っています。
そのためDBMSを変更などという事は時間的に不可能になり、Delphi7 + DBISAMをDelphi2007 + DBISAMに変更して急ピッチで完成に向けて作業を進めています。
解決したと言っていいのか分かりませんが解決としておきます。
ツイート | ![]() |