AccessとLinux

中小企業での販売管理プログラムの作成についての所感

使いにくい!?

2015年08月14日 13時26分13秒 | Weblog
最近、デリバリ担当が一週間入院して、代わりにデリバリをする機会があった。

販売管理プログラムで一般的な機能が問題なく使えるようになってから、こんな機能があったらもっと効率がよくなるとか、PCで印刷してしまえばこの手書き書類はなくなるとか、ここ10年考えてきた。しかし、実務をしてみると、さらに追加しなければならない機能があったり、修正しなければならないフォームがあったりで相変わらず、手直しがある。
運用し始めてもう13年目なのに。

自作したプログラムなので自分がいる間は管理できるけれど、後、数年もすれば還暦という年齢になると、今後のことを考えてしまう。会社で使っているので、会社が存続している間は何らか管理ソフトが必要だ。継続性が必要だ。

この件は今、考え始めたことでもなく、誰か代わりにプログラムを管理してくれる人を捜していたこともある。が、手直し手直しを続けたスパゲティコードは誰も理解できないだろうと、あきらめた。結局、現在使っているプログラムが管理できなくなったら、パッケージソフトを手直しして使うしかないだろうと思っている。それで作業量が増えれば、人を増やすしかないだろう。次の世代の問題だと思う。それで費用がかさむようなら、自分で別の方法を考えるべきだろう。

「パッケージソフトは使いにくい!」と聞くが、それは仕方ないことだと思う。今回、実際にデリバリ作業をして「使いにくい」ということがどういうことかよく考えてみた。

パッケージソフトは一般的な機能だけ備えたものだから、ここの仕事、ここの事業所だけの特殊な処理には対応していない。当たり前のことだ。「使いにくい、手間がかかる」の大半はこんなことなのだろうけれど、一般的な機能の中でも、こうすればよりクリック数が減るということもある。

Windowsを使っていると、「この設定画面はコントロールパネルからも出せるし、ここを右クリックしても表示できる」といったことは多い。パッケージソフトはあまり使ったことがないのだが、そこまで対応していないのではないかと思う。ここ数年、自作した販売管理ソフトの修正で、同じ画面を色々なフォームから呼びせるようにした。商品一覧から、売上明細、仕入明細を表示したり、売上明細から商品マスタの修正画面を出したり、仕入明細を表示したりできるようにした。

商品指定して売上明細を表示する機能はどのパッケージソフトでも備わっているだろう。けれども、売上伝票画面からカレント行の商品の売上明細を表示したり、仕入明細を表示したりする機能はないのではないかと思う。一度、売上伝票画面を閉じて、売上情報から商品指定して、という作業になるのではないかと思う。これだと非常に効率が悪い。

この入力画面からこの情報を表示したいということは、実際に作業する人でないと分からない。今なら、やってみて、「あ~、面倒くさい、ここにボタンを追加してしまえ!」とフォームを修正してしまう。

パッケージソフトではこういった機能の追加は結構難しい。販売管理ソフトのパッケージを発注する際、追加機能を仕様書に書かなければならないだろうが、使ってみなければわからない機能は書きようがない。修正に追加費用がかかってしまうようなら、「仕方ない、がまんして使おうか、、、」。結果、パッケージソフトは使いにくい、ということになってしまう。

「パッケージソフト+手直し」を発注する時、自社特有あるいは業界特有の事情を仕様書に盛り込むことはできる。それに加えて、既にある検索画面の呼び出しをボタンを追加してもらったり、マスターファイルの修正画面ボタン追加してもらうといったことは、なかなか仕様書に書きにくい。使ってみないとわからないから。

また、データ一覧をどのフィールドでソートするか、ということも指定しづらい。結局、項目名をクリックしたら、その項目でソートしてほしい、とか指定するしかないだろうが、これも使いながらでないと無駄な手直しになってしまう可能性が高い。結局、発注時の仕様書だけでは使い易いシステムにはなりにくい。継続的に費用をかけて手直ししていかないと使い易くならない。それでも納入業者の都合で、時期がくれば全く新しいシステムに更新しなければならないだろうし、新しいシステムを導入してしまえば、また一からやり直しだ。結局、外注ではいつまで経っても使い易いシステムは手に入らないということになってしまう。

それもまた仕方ないことか。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

PostgreSQLのyumによるインストール

2015年08月14日 08時15分09秒 | Weblog
今回のサーバー更新の感想。

ネットでPostgreSQLのインストールを検索すると、yumでのインストールを紹介しているページが多い。なので、yumでインストールするのが普通なのかもしれないが、いつもうまくいかない。
yumでインストールする時にどうしても納得がいかないところがある。
やはり、ソースからconfigure、makeすべきなのではないかと思うのだが。

1.initdbの--no-locale オプションは不要か?
いつもPostgreSQLをconfigure、makeして、initdbする時は--no-localeオプションを付けている。今回の更新でも--no-localeオプションを付けた。
ネットで検索しても9.4でこのオプションが必要なのかよくわからない。
このオプションが必要というのは「PostgreSQL完全攻略ガイド」(石井達夫著、(株)技術評論社)に出ていて、最後に買った改訂第5版P.46に記載がある。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
■忘れてはならない--no-localeオプション
 日本語環境で忘れてはななないのが--no-localeオプションです。PostgreSQLではOSが持つロケールデータベースを利用することができますが、日本語においてはこの機能はまったく必要ないばかりか、ロケールデータベースのバグのせいで検索処理に問題を起こすことさえあるので、この機能を無効化する--no-localeオプションを指定して未然にトラブルを防ぎましょう。このオプションを指定し忘れると、もう一度データベースクラスタの初期化をする羽目なります。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
とあって、この版はPostgreSQL8.1を想定している。9.4でこのオプションが必要なのかどうか調べてみたのだが、よく分からない。
yumでインストールした場合、serviceから呼び出されたinitdbのオプションは無視されるようで、もし--no-localeオプションが最新バージョンでも必要なら「yumでのインストールは問題あり!」ということになってしまう。

2.postgresのホームディレクトリが/var/lib/pgsql/9.4/になってしまう
運用時にはサーバーにはディスプレイを付けていない、telnet接続してバックアップをとっている。telnetは通常rootでログインできないので、postgresでログインするのだが、.bashrcの保管場所が/var/lib/pgsql/9.4/、PostgreSQLのデータディレクトリになってしまい、これが非常に気持ち悪い。
バックアップは別に用意した共有ホルダーに保存しているのだが、ログイン直後に大事なデータベースデータが保管されたディレクトリがホームディレクトリになってしまうのは怖すぎる。


たしかにPostgreSQLをソースからインストールするのはyumでインストールする場合よりも手順が増える。また、「2」postgresのホームディレクトリを変更することはできるのだが、その手間と「1」の心配を合わせて考えると、PostgreSQLはyumでインストールすべきではないと思う。

yumでPostgreSQLをインストールするとユーザーpostgresが自動作成されるが、Linuxのadduserコマンドでアカウントを作成した場合と作成後の状態が異なる。PostgreSQL以外のアプリケーションで例えば、emacsをyumでインストールしても特定ユーザーが追加されることはない。PostgreSQLではスーパーユーザーpostgresが追加されるという他のアプリケーションとは違った動作をする。
initdb時には--no-localeオプションを付けた方が安全そうだし、データディレクトリを状況に合わせて指定したい場合もある。オプションが無視されてしまう、serviceからの実行は使いにくい。
現状では最新の9.4でもソースにCentOS7で使える自動起動スクリプトが「contribute」に含まれていない。CentOS6用の自動起動スクリプトは含まれているのだが。yumでインストールすると、起動スクリプトが同時にインストールされるので、自動起動の設定が簡単だ。しかし、この点を考慮してもデータベースの需要性を考えると、やはりyumでインストールするより、ソースからconfigure、makeしてインストールすべきなのではないかと思う。

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

VPN経由でサーバーに接続

2015年08月01日 08時53分01秒 | Weblog
会社のほとんどのPCは同一フロアで販売管理プログラムを使っているのだが、2台だけはVPN経由で17kmくらい離れた事務所(H事務所)で使っている。インターネットはNTTの「隼」、ルーターはヤマハRTX810を使っている。環境は整えている方だと思う。

販売管理ソフトはAccess2007。PostgreSQL7.4.4のテーブル、ビューをODBCでリンクしている。

H事務所の2台のPCはVPN経由でサーバーに接続しているのだが、この動作がまあ、遅い。画面によっては開くのに30秒かかってしまう場合もある。サーバーを入れ替えたら改善されるかと思ったが、それほどでもなかった。結局、プログラムを見直すことにした。

これまで、複雑なクエリーはサーバーでビューを作っておいてリンクする形にしていた。クエリーを1回飛ばせば必要なデータが全て得られる。細かいクエリーを何度も飛ばすのではなく、クエリーの回数を極力少なくするようにしていた。その方が高速かと思っていたが、今回、見直しの中でそうではないことがわかった。

サーバー内のビューの作成はサーバー内で行われる。それをテーブルとして参照するAccessには何ら負荷がかからないものと思っていた。データは多少、大きいかもしれないが、直リンクした商品テーブルほどでもないので、通信量を考えると「商品テーブルを開くほどには時間がかかるはずがない!」と思っていたのだった。しかし、結果は商品テーブルが2秒で開くところ、複雑なクエリーで定義したビューは30秒かかってしまう。

試しにビューをやめて、Access内のクエリーをソースしてみてもやはりフォームが開くのに相当時間がかかる。クエリーのjoinをやめると、直ぐ開く。基礎となるテーブルには担当者CDが保存されていて、その担当者名をリンクしたテーブルを開くのは遅いのだが、基礎テーブルは直ぐ開く。データ量はそれほど変わらない。通信速度は関係なさそう。

じゃ、フォーム内の担当者名のソースをAccessのDlookupでレコードごとに問い合わせる形にするとどうかというと、これは直ぐ開く。クエリーの回数はこの方が格段に多い。なんせ、レコードごとに担当者名を問い合わせしているのだから。

同じフロア内のPCでは実用上問題ない速度で開くフォームも、VPN経由だと非常に時間がかかってしまう場合がある。複雑なクエリーをソースとしたフォーム。そのクエリーをサーバー内でviewを定義してやっても改善しない。フォームのソースはできるだけjoinしない単一テーブルにして必要な項目はDlookupで検索した方が高速、、、、、ということに。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする