SQL2005とAccess:

お世話になります。
これまで、主に部門内でのデータ集計をAccess(単独のクライアント)で行っていたのですが、複数でデータ操作を行いたい・・・というリクエストが増えてきました。
一番簡単なのはデータサーバーにMDBを置いて、処理用のフォームやクエリをクライアント側に設置ですが、やはりMDBでは速度や安定(障害)で不安が残ります。

そこで、SQl2005に現状のデータをインポートして、クライアントにAccessでテーブルリンクを貼って、操作しようと考えています。

この場合に、特に注意する点、特に問題になりやすい点、などありましたらご教授ください。

回答の条件
  • 1人1回まで
  • 登録:2009/05/06 08:55:34
  • 終了:2009/05/11 06:42:22

ベストアンサー

id:memo77 No.2

memo77回答回数238ベストアンサー獲得回数202009/05/06 10:43:30

ポイント35pt

もしかして各ユーザーがそこそこスキルがあって、リンクテーブルを元に自分たちで好き勝手にクエリを組むような状況でしょうか。

人によってはフォームやレポートで何か作ったり。

うちがちょうどそういう状況なんですが、もしそういう状況であれば、そこそこ諸刃の剣なので体験的な注意点をいくつか。

ユーザー権限はきちんと設定されていますか?
saアカウントやdbo権限を持つアカウントに適切にパスワードが設定されていますか?お勧めはActive Directoryと連動させたセキュリティ接続で、YourDomain\Domain Usersに必要なテーブルの読み取り権限(場合によっては部分的な書き込み権限)を与えることです。読み取り専用のユーザーIDを作成してパスワードを布告した場合、情報の流出などがあっても誰がアクセスしたかを判断するのは困難になりますので注意してください。パスワードを保存したMDBを配布したとしてもバイナリを見るとパスワード丸見えなので注意。

SQLServerは基幹システムではないですか?
もし接続させようとしているSQLServerが基幹システムや重要なシステムが動いているサーバーであれば、ユーザーの処理内容によっては負荷の影響が無視できません。アクセスにはパススルークエリという手法もあり、組み方によってはSQLServerをダウンさせるような膨大な処理量のSQLを投げることも可能です。

根幹的なデータには直接アクセスさせない
「現状のデータをインポート」とあるので、おそらく副次的なデータだとは思うのですが、もしそのデータの損失が経営に大きく影響するようなものであれば、ユーザーに直接リンクさせるべきではありません。SQLServerのユーザー権限を適切に設定すれば読み取り専用にすることもできますが、二重化の意味も含め、日次バッチなどで別データベースに複製したものにアクセスさせるのをお勧めします。

本当にその処理は効率的ですか?(書き込み編)
複数のユーザーがリンクテーブルに対して直接データを登録しているのなら、もしかしたらきちんとアプリケーションにする必要があるのかもしれません。また、「特定のデータがあること」を前提として処理をしたものの、他のユーザーがデータを変更・削除して、誤った結果になっていても気づかないかもしれません。リンクテーブル経由で書き込みを認める場合は、業務ルールをしっかり定める必要があります。

本当にその処理は効率的ですか?(読み取り編)
取り扱うレコード数にもよるのですが、アクセス上のテーブルとリンクテーブルを結合した処理は、あまりよい動作をしません。例えばアクセス独自の関数を使った集計クエリなどはSQLServerのリンクテーブルに対して、アクセス上にいったん全データを取得する動作をします。IIFを含んだ1000万件のレコードのSumとか考えたくもないですw。ユーザーは最終的なデータが取得できれば「仕事ができている」と思いがちですが、実は1クエリに30分かかるような処理がパススルークエリを使えば10秒で終わったりもします。アクセスはクエリ待ちの間CPUリソースを食い潰すので他の作業ができず、実は効率が落ちていたりします。ユーザーがどんな処理をしているか拾い上げて、こまめに指導したほうがよいかもしれません。

ユーザーや業務の流動性を考慮していますか?
上記の内容に対して「ユーザーはそこまでできないから大丈夫」「ユーザーは理解しているから大丈夫」と手抜きしていませんか?いまは大丈夫でも、人事異動などですばらしく技術の高いユーザー、致命的な処理を平気でするユーザーが来るかもしれません。どんな人が来ても対応できる(最低限教育できる)ようにしておきましょう。

書けばいくらでもあるのですが、これ以上はどこまでの作業をどのレベルで許可するかでまったく違うので、具体的な事例があるようであれば、また別途質問を立ててください。

答えられる範囲で答えますー

id:masyuta

いろいろと詳しい内容、ありがとうございます。

今後検討したい内容がたくさんあります。

じっくりと勉強したいと思います。

2009/05/06 10:53:11

その他の回答(2件)

id:pahoo No.1

pahoo回答回数5960ベストアンサー獲得回数6332009/05/06 09:25:25

ポイント35pt

「SQl2005」とは「SQL Server 2005」のことですか。

でしたら、シングルユーザーからマルチユーザーへの移行ということで、下記の点に注意してください。


排他制御とロック
同時に複数のユーザーが同じレコードを更新した場合の処理。たいていはRDBMS側で処理してくれますが、アプリケーションの方でも、必要に応じてレコードにロックをかけるなどの処理を加えるべきです。
トランザクションとコミット
RDBMSでは処理の最適化を行うため、トランザクションが終わった都度、コミットを行い、DB内容の更新を行います。これもSQL Serverにお任せでも良いのですが、DBがダウンしてしまった場合のことを考え、トランザクションの概念は組み込んでおいた方がいいです。
ユーザー権限
すべてのユーザーがすべてのテーブルの参照/更新ができるというのは危険です。業務上、必要最小限にとどめるべきです。また、売上情報など、上位ユーザーが認証したら、下位ユーザーが変更できないような処理を組み込んでおく必要があります。
ログ採取
だれが、いつ、どんな情報にアクセスしたかの履歴をとっておく必要があります。これはSQL Serverにお任せで構いません。

以上のような処理は、Accessでリンクを張っただけではできず、VBAで制御をかけてやる必要があります。

id:masyuta

さっそくありがとうございます。

>SQL2005

はい SQL Server 2005 です。

>排他制御

>トランザクション

この2点について検討します。

排他制御はこれまでAccessでレコードレベルで

ロックしていただけなので勉強します。

他の点はそれなりに理解出来ているみたいです。

2009/05/06 09:38:01
id:memo77 No.2

memo77回答回数238ベストアンサー獲得回数202009/05/06 10:43:30ここでベストアンサー

ポイント35pt

もしかして各ユーザーがそこそこスキルがあって、リンクテーブルを元に自分たちで好き勝手にクエリを組むような状況でしょうか。

人によってはフォームやレポートで何か作ったり。

うちがちょうどそういう状況なんですが、もしそういう状況であれば、そこそこ諸刃の剣なので体験的な注意点をいくつか。

ユーザー権限はきちんと設定されていますか?
saアカウントやdbo権限を持つアカウントに適切にパスワードが設定されていますか?お勧めはActive Directoryと連動させたセキュリティ接続で、YourDomain\Domain Usersに必要なテーブルの読み取り権限(場合によっては部分的な書き込み権限)を与えることです。読み取り専用のユーザーIDを作成してパスワードを布告した場合、情報の流出などがあっても誰がアクセスしたかを判断するのは困難になりますので注意してください。パスワードを保存したMDBを配布したとしてもバイナリを見るとパスワード丸見えなので注意。

SQLServerは基幹システムではないですか?
もし接続させようとしているSQLServerが基幹システムや重要なシステムが動いているサーバーであれば、ユーザーの処理内容によっては負荷の影響が無視できません。アクセスにはパススルークエリという手法もあり、組み方によってはSQLServerをダウンさせるような膨大な処理量のSQLを投げることも可能です。

根幹的なデータには直接アクセスさせない
「現状のデータをインポート」とあるので、おそらく副次的なデータだとは思うのですが、もしそのデータの損失が経営に大きく影響するようなものであれば、ユーザーに直接リンクさせるべきではありません。SQLServerのユーザー権限を適切に設定すれば読み取り専用にすることもできますが、二重化の意味も含め、日次バッチなどで別データベースに複製したものにアクセスさせるのをお勧めします。

本当にその処理は効率的ですか?(書き込み編)
複数のユーザーがリンクテーブルに対して直接データを登録しているのなら、もしかしたらきちんとアプリケーションにする必要があるのかもしれません。また、「特定のデータがあること」を前提として処理をしたものの、他のユーザーがデータを変更・削除して、誤った結果になっていても気づかないかもしれません。リンクテーブル経由で書き込みを認める場合は、業務ルールをしっかり定める必要があります。

本当にその処理は効率的ですか?(読み取り編)
取り扱うレコード数にもよるのですが、アクセス上のテーブルとリンクテーブルを結合した処理は、あまりよい動作をしません。例えばアクセス独自の関数を使った集計クエリなどはSQLServerのリンクテーブルに対して、アクセス上にいったん全データを取得する動作をします。IIFを含んだ1000万件のレコードのSumとか考えたくもないですw。ユーザーは最終的なデータが取得できれば「仕事ができている」と思いがちですが、実は1クエリに30分かかるような処理がパススルークエリを使えば10秒で終わったりもします。アクセスはクエリ待ちの間CPUリソースを食い潰すので他の作業ができず、実は効率が落ちていたりします。ユーザーがどんな処理をしているか拾い上げて、こまめに指導したほうがよいかもしれません。

ユーザーや業務の流動性を考慮していますか?
上記の内容に対して「ユーザーはそこまでできないから大丈夫」「ユーザーは理解しているから大丈夫」と手抜きしていませんか?いまは大丈夫でも、人事異動などですばらしく技術の高いユーザー、致命的な処理を平気でするユーザーが来るかもしれません。どんな人が来ても対応できる(最低限教育できる)ようにしておきましょう。

書けばいくらでもあるのですが、これ以上はどこまでの作業をどのレベルで許可するかでまったく違うので、具体的な事例があるようであれば、また別途質問を立ててください。

答えられる範囲で答えますー

id:masyuta

いろいろと詳しい内容、ありがとうございます。

今後検討したい内容がたくさんあります。

じっくりと勉強したいと思います。

2009/05/06 10:53:11
id:AZUY No.3

AZUY回答回数343ベストアンサー獲得回数122009/05/06 20:50:36

ポイント10pt

>そこで、SQl2005に現状のデータをインポートして、クライアントにAccessでテーブルリンクを貼って、操作しようと考えています。

多くのところはこういうやり方を採用しないので、実情は分からないと思いますよ。

「クライアントにAccessでテーブルリンクを貼って、操作しよう」というのが、無理があって

これでも安定動作は望めないと思われます。

あと、速度的に遅いのは遅いと思います。大量データを扱わないのなら問題ないとおもいますが・・。

id:masyuta

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

しかし設問は

>この場合に、特に注意する点、特に問題になりやすい点、などありましたら

という前提になっています。

SQLをバックエンドにAccessをフロントエンドにする考えは

SQLから構築するのに比べたら性能や安定性において劣っているのは

お聞かせいただかなくても理解しています。

しかし、構築したリソースの多くを破棄してSQLサーバーで再構築するだけの

原資とマンパワーが無いのです。

2009/05/06 21:14:00

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません