• ベストアンサー

ACCESSとの比較・連携について

SQL Server2000の評価版(120日有効)があると知り、早速インストールしてみました。 そして、1000万レコードのCSVファイルを試しに作ってみまして、まずインポート処理がACCESSよりどのぐらい速いか比較してみました。 そうすると逆に、SQL Server2000の場合はトランザクションログを吐くためか、3倍近く長い時間がかかってしまいました....。 そしてグループ化&合計を算出するクエリーを走らせてみたところ、これまたACCESSのほうが速い結果になりました。 大量データを集計する業務をする都合があって、処理が速いと期待されたSQL Serverが本当にそんな程度なのか甚だ疑問なのですが、何か良いアイデアや私のやり方での問題点はないでしょうか? また、クエリー作成などはACCESSのやり方に馴染んでるのですが、SQL Serverだと更新クエリーといったものがないんですね。 ACCESSからADPとかいうのでやろうとすると、ビューはあっても更新クエリー的なものがないですし、ACCESSからODBCで接続すると大量データの場合はタイムアウトになってしまうし。 なんかACCESSに馴染んだ人にはちょっと壁がありすぎるのですが、何か良いアイデアはないでしょうか?

質問者が選んだベストアンサー

  • ベストアンサー
  • Azzuri
  • ベストアンサー率68% (34/50)
回答No.2

データが10万件以下でシングルユーザーでの使用、 また複雑なSQLを使用せず、インデックスに期待しない、 なおかつ障害発生時の復旧を考えなければAccessで 十分だと思います。 (Accessだと1万件以上のロールバックに基本的に 対応していません。レジストリの設定が必要になり 、動作が不安定になります。) インポート処理に限って言えば、インデックスを一時 的にはずした方が良いでしょう。格段に早くなります。 ログに関してですが、DBの復旧モデルを「一括ログ記録」 にして下さい。デフォルトでは「フル(完全)」に なっています。一時的に大量の更新を行う場合等は、 「一括ログ記録」にして、ログの記録を抑えたほうが 効率的です。

すると、全ての回答が全文表示されます。

その他の回答 (1)

  • kokegon
  • ベストアンサー率78% (22/28)
回答No.1

>3倍近く長い時間がかかってしまいました....。 ファイルの自動拡張が有効になってませんか? 自動拡張が有効だと拡張時に大幅にパフォーマンスが悪くなります。あらかじめファイルの領域を確保しておくといいですよ。 >そしてグループ化&合計を算出するクエリーを走らせてみたところ、これまたACCESSのほうが速い結果になりました。 インデックスはちゃんと設定してありますか? ちなみに mdb のクエリは adp のストアドに対応します。 ビューはあくまでも論理テーブルとして利用してください。 ODBC は遅いので OLEDB を使用するといいですよ。

noname#257070
質問者

お礼

ご回答ありがとうございました。

noname#257070
質問者

補足

初回にやった時、自動拡張で時間がかかったことに気付いたので、 次回は大きい容量で領域確保しましたが、やはりACCEESSより時間がかかりました。 接続方法もODBCではなく、OLE DBを使いました。 トランザクションログ出力が余計に時間を食ってる最大原因だと思います。ファイル容量も実際のデータファイルの2倍以上でしたし。 インポート処理でトランザクションログの書き込みを拒否する方法はないもんでしょうか。 あとインデックスは未設定でしたので、今度やってみますが、いずれにせよ単純な処理であれば、ACCESSのほうが有効そうな気がしました。

すると、全ての回答が全文表示されます。

関連するQ&A