過去の桐井戸端BBS (桐ver.8) |
15385 | LANでシステムを構築するとき桐とアクセスではどちらがよいのでしょうか | くろ | 2002/03/07-21:19 |
教えて下さい。 現在、私は桐V8sp6で会社の会員情報等の管理を担当しております。(一台で) (ほとんどマニュアル処理、一括処理は2個程度です) 今度、経理とのシステムの統合を計画しており、外部にソフトウエアをオーダーするのですが、桐かアクセスかで悩んでおります。 桐暦は4年でアクセスと比べて使いやすさは充分解ります。 しかし、桐は外注するエンジニアの方にLANで何台でおなじTBL表を見に行ったりするには、処理が重たく不向きだと言われました。 レコードロック機能があるはずなのにそうなのでしょうか? もし、LANで数台でWIN桐のシステムを稼働させていらっしゃる方がおられたら、教えて下さい。 | |||
15389 | Re:LANでの桐の作動について教えて下さい | 佐田 守弘 | 2002/03/07-22:59 |
記事番号15385へのコメント くろさん 質問の件は、クライアントが何台あるかで答えが変わるでしょうね。 LANで数台から数十台規模のクライアントで桐を稼働させている例は少なくないと思います。 外注先のエンジニアの方の言われた意味は次の通りです。 桐の場合、サーバは単なる共有データの置き場所で、各種のデータ処理はクライアント側で行います。 つまり、何か処理をする度に、サーバからクライアント側にデータを取り寄せて クライアント側で処理するので、その度に表データそのものがLAN上で行き交います。 もちろん、毎回表の全データが通信されるわけではないのですが、絞り込みの様な処理をしたり、 結合表を実行しようとすると、どうしても全データをサーバからクライアントに取り込む必要があります。 このために、数百台とか数千台の程度の大規模なシステムになると、LANに負担が掛かるのは事実です。 一方、大規模向けのDBは、サーバ上でDBエンジンを稼働させている様です。 つまり、クライアントはサーバに対してクエリーなどを発行し、サーバ側に データ処理をさせて、その結果だけを取り寄せます。これによってLANの負荷を少なくしているはずです。 しかし一方で、桐はデータの元がサーバにあっても、それをクライアント側で 直接触れるために、様々な点で操作性が良いのです。 表データを直接見る事ができず、クエリーで作り出された結果だけしか見られない DBでは、そう言った小回りの利く使い方には限界があります。 質問の件は、数台のクライアントとの事ですから、ネットワークがしっかりしていれば、 それ程負担にはならないと思います。 ただし、データの規模を見ているわけではないので、あくまでも参考までです。 佐田守弘(KS-00119) | |||
15393 | Re:LANでの桐の作動について教えて下さい | MIT | 2002/03/08-11:06 |
記事番号15385へのコメント くろさん >もし、LANで数台でWIN桐のシステムを稼働させていらっしゃる方がおられたら、 >教えて下さい。 私は桐を使ったファイル共有システムをいくつか組んだ事があります。 サーバーにTBLを置いて各クライアント側で桐が稼動するものです。 負荷が高そうな例としては データ件数:同時使用で更新される表が最大のもので約10万件 同時使用クライアント数:6台 サーバーOSはWinNT4.0 クライアントOSは全てWin98SE ネットワークは100BaseTXでスイッチングハブにより結線 で編集しているものがありますが、特に問題なく使われています。 本掲示板でも何度かお話がありましたが、 桐のファイル共有使用で注意すべき事は、共有でかつ、更新モードで 桐を使う時は索引が効かない事です。 索引の有無で動作速度が左右される処理は、ある程度のデータ件数になると 工夫しないと実用的では無くなる場合があります。 桐がファイル共有で「重い」評判の所以はこの辺りにあるのかも知れません。 しかし、先にご紹介した事例では入力を電話対応により行っており、 電話を受けながらの入力で要求されるレスポンスは十分に出ていると思われます。 佐田先生もおっしゃられているネットワークの形態やデータ件数にもよりますが、 桐によるファイル共有の実用性は組み方次第だと思います。 くろさんのお話ではほとんどマニュアル操作との事ですので、桐を選択する意義は大きいと思います。 なお、桐に限りませんがファイル共有型システムでレスポンスを高める 最も簡単な方法はクライアントパソコンの仕様を上げることです。 つまり定期的な買い替えです。実にもったいない話しで地球環境にも良くない事ですが、 クライアント台数やデータ件数の増加に対しては有効です。 導入に際してはこれも検討されると良いと思います。 以上ご参考まで。MIT | |||
15400 | Re:LANでの桐の作動について教えて下さい | くろ | 2002/03/08-22:10 |
記事番号15389へのコメント 佐田 様 早速に教えて下さりありがとうございました。 会員データは2500程あります。 退会した方のデータもあるので5000は超えてしまいます。 列項目は12個ほど。 このテーブル表で煩雑に絞り込み、修正、それと他の表でもこの表を併合で利用しています。 この程度ならLANで大丈夫でしょうか? データーサーバー1台、クライアントが3台の予定です。 会員テーブル表で入力、修正、絞り込みや行集計している最中に、経理の方では 会員テーブル表の会員コードを参照しようとするときの動きはどうなるのだろうか。 少し心配です。 プロの桐VARのSEさんならきっとうまくシステムを作ってくださるのとは 思うものの、私自身も納得のいく形でシステムを依頼したいので、 この掲示板に書かせて頂きました。 | |||
15403 | Re:LANでの桐の作動について教えて下さい | 佐田 守弘 | 2002/03/09-00:04 |
記事番号15400へのコメント くろさん >会員データは2500程あります。 >退会した方のデータもあるので5000は超えてしまいます。 >列項目は12個ほど。 は、桐からすれば全く問題ないほど少量のデータだと思います。 おそらくファイルサイズは1〜数MB程度ではないでしょうか。 頻繁にアクセスしてもそれ程のトラフィックにはならないと思うのですが。 >このテーブル表で煩雑に絞り込み、修正、それと他の表でもこの表を >併合で利用しています。 繁雑とはどの程度の頻度かも関係しますが、修正(編集)は全く問題にならない負荷だと思って下さい。 実際に試したわけではありませんが、編集だけであれば、 かなりの人数が一斉に編集を行ってもびくともしないはずです。 絞り込みとか、行集計は、表全体をなめますから、少しは負荷になります。 とは言え、3台のクライアントなら、まず問題になる程の影響はないと思います。 レコードロックとの関係で言えば、Aさんがa行目のデータを編集しているとします。 この時にBさんは、a行目のレコードを参照できますが、編集はできません。 そしてAさんが編集を終えると、その結果がBさんの画面に反映されます。 そしてBさんはその結果をまた編集する事ができます。 そして、その編集中は他の人は編集ができなくなります。 大体、その様な動きをすると思って下さい。 適切な例でないかも知れませんが、書架に多数の本があり、何人かがそれを読もうとしているとします。 誰でも書架にある本を自由に手にとれます。しかし、ある一冊の本を手にとれるのは早いもの勝ちで最初の一人だけです。 後の人は、読んでいる人の隣で覗き見はできますが、ページはめくれません。 その人が本を書架に返したら、別の人が手にとって読む事ができます。 レコードロックとはその様な機能です。 なおコマンドの中には、表全体に対して一気に処理するコマンドがあります。 置換の様なコマンドがその例です。 この様なコマンドを実行するには、表全体をロックしなければならないため、 その時だけ他のユーザーは参照だけしか利用できなくなります。 逆に他のユーザーが編集している時には、その様な表全体をロックするコマンドは実行できません。 ただし、ロックコマンドや、トランザクション関連のコマンドをうまく使う事によって、 多量のデータを処理する事ができるはずです。 なお、VAR業者さんに頼んだ場合には、まさか会話処理で行う様な組み方はしないと思いますから、 操作方法はかなり変わって来るかと思います。 このあたりは実際の場面を見ていないので、あくまでも私の予想として受け止めて下さい。 佐田守弘(KS-00119) | |||
15408 | Re:LANでの桐の作動について教えて下さい | くろ | 2002/03/09-19:25 |
記事番号15393へのコメント MIT様 具体的なシステム例を教えていただきありがとうございます。 データ件数10万件、電話でのレスポンスときき安心いたしました。 私どもは、サーバー、クライアントともWIN2000で稼働させるつもりです。 サーバー機は今から購入しなければいけないかもしれません。 サーバー機はクライアント機より能力がだいぶん高くないといけないのでしょうか? > >なお、桐に限りませんがファイル共有型システムでレスポンスを高める >最も簡単な方法はクライアントパソコンの仕様を上げることです。 定期的なpcの買い換えは、データベースが増大化したら必要ですね。 アクセスと桐の比較で、 アクセスはOS、アクセスバージョンが上がったとき、 結構、不具合が出ると聞き、桐の方が安心かなと思っています。 >くろさんのお話ではほとんどマニュアル操作との事ですので、桐を選択する >意義は大きいと思います。 今はマニュアル操作ですが、システムを組んでもらったら、 ボタン化されラクになる反面、少し、やりづらい面もあるかと思います。 なんとか、いいシステムを目指したいです。 くろ | |||
15409 | Re:LANでの桐の作動について教えて下さい | くろ | 2002/03/09-19:29 |
記事番号15403へのコメント 佐田 様 桐初級の私にわかりやすいご説明ありがとうございます。 編集ではほとんど負担なくできるのですね。 安心いたしました。 会員の元データで、集計や複雑な絞り込みなどをする人は、 今は私だけですが、他の人もできるように、 業者さんにとよく話し合って、ボタン化できるところはしてもらおうと思います。 じっくりデータの統計等を行うときは、元データをコピーしてから、 そこで思う存分作業すれば、他の業務にも負担をかけないでしょうね。 くろ | |||
15410 | Re:LANでの桐の作動について教えて下さい | 清水 泰行 | 2002/03/09-23:12 |
記事番号15385へのコメント 桐もACCESSも基本的にはファイル共有型ですから、 似たようなものだと、個人的経験からいえます。 ODBCという仕組みを利用してSQLサーバーというデータベースや オラクルというデータベースを桐やACCESSから利用する方法もありますが、 価格が高くなるので、クライアント数によりますね。 ファイル共有で利用した場合、ACCESSのほうが むしろテーブルが壊れやすいと個人的には感じています。 | |||
15412 | Re:LANでの桐の作動について教えて下さい | くろ | 2002/03/10-10:32 |
記事番号15410へのコメント 清水 様 ありがとうございました。 システムの設計がどちらの方がよいか、「アクセスか桐か」 聞く人によって、違っていて、迷っていました。 清水様のお話、参考にさせていただきます。 くろ | |||
15423 | Re:LANでの桐の作動について教えて下さい | MIT | 2002/03/11-12:33 |
記事番号15408へのコメント くろさん >サーバー機はクライアント機より能力がだいぶん高くないといけないのでしょうか? ファイルサーバーとして使うだけでしたら、主に要求されるのはハードディスクのレスポンスになると思います。 無論、信頼性も必要ですが、CPU能力など高い演算性能は重要な要素ではありません。 将来はSQL系言語を使った照会型システムに移行する計画があればしっかりした サーバーを導入される意義は大いにあると思います。 しかし、そのような計画が無いか、かなり先の話しであれば、 あまり高性能で高価なサーバーを導入されても高い投資対効果は得られないと思います。 >アクセスと桐の比較で、 >アクセスはOS、アクセスバージョンが上がったとき、 >結構、不具合が出ると聞き、桐の方が安心かなと思っています。 これは桐が有利な条件にはならないと思います。 出始めのものは必ず不具合があると思って対応するしかありませんね。 ただ、桐は既存ユーザーの経験がバージョンアップしても生かせる事がアクセスと比較して多々あると思います。 本掲示板に登場される回答者の皆様の層の深さは「桐ならでは」ですね。 >今はマニュアル操作ですが、システムを組んでもらったら、 >ボタン化されラクになる反面、少し、やりづらい面もあるかと思います。 >なんとか、いいシステムを目指したいです。 前回、桐をお勧めしたのは、仮に一括処理などで自動化されたシステムであっても 表形式編集の手段は必ずあると思うからです。 必要に応じて元表をコピーして使う分にはシステムに影響する事もありませんので システム中の表の構成を理解しておけば、何かと便利な事もあると思います。 目的達成のための最良の手段としてシステムができると良いですね。MIT |