- - PR -
桐からのシステム再構築
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2008-04-14 18:14
はじめまして。いきなり長い本文で申し訳ございませんが、よろしくお願いいたします。
桐で作成されたシステム(台帳の入力と印刷。1PCのみで運用)を、複数ユーザで行なえるようにシステム再構築を行なう案件を担当しています。 要件は ・複数ユーザ(最大10クライアント、同時は4、5クライアント) ・台帳(データ)の入力と、台帳を集計・集約した帳票の出力 ・帳票形式としては、出力後変更不可なものや編集可(EXCEL)両方有 クライアント数も限定(これ以上増える見込みなし)ということで、WEBではなくC/Sで開発することに決まってます。 当初、 ・DB:Access − テーブルリンク −Clinent:Access(フォーム、レポート) ・DB:Access − ODBC経由 −Clinent:VB.NET ※OSはサーバ、クライアント共にXP ※ClientにVB.NETが出てきたのは開発を3名体制で行なうため、 この方が分担して開発しやすいという意見から。 のどちらかと考えていましたが、色々検索してみると、 「Accessはマルチユーザに弱い」 「マルチユーザだと(注意しないと)MDBが壊れる」 といった情報を見かけました。 そのため、この構成、特に、「DBがAccess」という点に不安が出てきました。 そこで今考えているのは ・DB:PostgreSQL − ODBC経由 − Clinent:VB.NET が一番無難かと考えてます。 (本当はOracleにしたいのですが(経験ありますし)、客先予算の都合上Oracleは採用できません) が、正直クライアントAccessも捨てがたい以下の点があります。 ・画面は台帳の入力と帳票の出力指示、いくつかの入力補助のダイアログ画面程度 (凝った画面はなく、ほとんど1画面対1テーブル、または1画面対ヘッダテーブル+明細テーブルのものばかり) ・現在分かっている帳票レイアウトを見る限り、Accessのレポートだと出力しやすそうな帳票。 ・Access経験豊富者が実装のメイン ということで、クライアントとしてはAccessが一番開発がしやすいと見ています。 また、先の「Accessはマルチに弱い」という情報も最新のAccess2007の情報ではなかったので、最新なら”マシに”なっているのでは・・・ という期待も捨てられません。 それにクライアントのVB.NETには 「帳票の実装」 で多少不安があります。 帳票ツールとしてはCrystal Reports(またはActive Reports)とEXCELになると考えています。 ここの不安材料は、 ・VB.NETでのCrystal Reports経験者なし。 ・VB6でのExcel操作は慣れているが、VB.Netでレイアウト(罫線など)の決まったExcel出力の経験者はなし(表形式でデータ出力ならあり) などです。 このようなケースの場合、 ・DBとクライアント(開発ツール)には何が考えられるか。 または ・実際にAccessでもこうなら出来ました。 といったような、色々なご意見をお聞かせいただけないでしょうか。 よろしくお願いいたします。 | ||||
|
投稿日時: 2008-04-14 19:03
正式ライセンスがある環境で開発しているので、私は採用した事は無いですが、
検討する余地はあるのではと思います。http://www.itmedia.co.jp/enterprise/articles/0511/01/news026.html | ||||
|
投稿日時: 2008-04-14 19:18
Microsoft Access という製品は、ファイルベースのDBMS + DBクライアント + フォームツール + レポートツール、の複合製品ですので、壊れやすいという DBMS のところだけを、OLE DB や ODBC でアクセスできる好きな DBMS に差し替えればそれで良いのではないでしょうか。 Access はプログラムも MDB に入れるという良く考えたらとんでもない仕様なので、開発中は壊れやすいかもしれませんが、こまめにバックアップしておけば良いでしょう。運用時はプログラムは書き換えませんので別にプログラムが MDB に入っていても関係ありません。 (もっとも MDB もちゃんと使えばそんなに壊れるものではないとは思いますが。) | ||||
|
投稿日時: 2008-04-15 21:49
m.m.様、unibon様 ご返答ありがとうございました。
FreeのOracleってあったんですね・・・知りませんでした。 現在のところ、やはり開発効率を考えるとAccess1本にしようかな・・・とかなり気持ちが傾いてます。 unibon様のご意見のように、確かにDB部分に不安があるなら、 「Accessはクライアントと割り切ってODBCで他DBとテーブルリンクする場合になるかも」 と想定して実装しておけば、DB部分で不都合がでてもなんとかなるかと思ってます。 それに、クライアント側のACCESSはDB側ACCESSのテーブルをテーブルリンクで利用する仕組みになるでしょうから、DBがACCESSでも他DBでもそんなにクライアント側の実装が変わることはないと見てます。 また、社内でもう少し相談したところ、実際にACCESSでマルチユースをしている事案がありました。 その担当者に聞いてみたところ 「最適化とか、1クライアントが長いあいだMDBを占有(ロック)するような処理がある場合は注意が必要。」 とのことでした。 今回の事案は、システム自体にはバッチ処理のようにトランザクションが長くなるような処理はないですし、 最適化もタイミングを見計らって出来るよう運用ベースでフォローできるかと考えてます。 |
1