今回、データベースはPostgreSQLを使用させてもらいました。
(ありがとうございます!)
もし、クライアントが2台以上あるなら、クライアント・サーバー型のデータベース構造にすべきです。(最近は3層構造なるものもあるようですが、良く知りません。) 私は、クライアントはAccessを使用してプログラムを作成していますが、Accessをデータベースとして使用しているわけではありません。給与計算ソフトはAccessをデータベースとして使用していますが、これは自分しか使用しないので特にクライアント・サーバー型にする必要はないと思っているからです。明細行も20人程度なので、月々20明細増える程度です。この程度ならAccessをデータベースとしても問題ないと思います。
PostgreSQLがなかったら自作はありえませんでした。以前はBtrieveを使用していたのですが、Btrieveと比べると多少重いかもしれませんが、非常に使い易いです。
「PostgreSQL完全攻略ガイド 石井達夫著」がよかったのか、セッティング、テーブルの作成変更、データのインポートなど非常に簡単でした。
BtrieveからPostgreSQLへのデータの移行はTakeMagic~Excel~Access+ODBCで行いました。まあ簡単です。
バックアップするにしても、Btrieveの時はサーバーにあるファイルごとバックアップをとっていました。(他にも方法があったのかもしれませんが、外注したベンダーからは「ファイルまるごとコピー」の方法しか教わりませんでした。)
PostgreSQLの場合はpg_dump というダンプコマンドからテキストファイルにしてバックアップをとります。バージョンアップの際もこのダンプデータをリストアすることで行います。作業的には簡単です。しかも、ダンプ時にロックがかかりません。ファイルまるごとコピーの場合はその間、データにアクセスするクライアントがあると、コピーは失敗してしまいます。
Btrieveの時は最終的にファイルの大きさが300MByteくらいありましたが(プログラムも含めて)、バックアップは結構大変な作業でした。挙げ句のはてに、コピー時にデータを失い、前日のデータに戻って改めてその日のデータを打ち直しすることが2回位ありました。データを失うというトラブルはその時しかありませんでした。安全のためにデータを保存する作業中にデータを失ってしまうという、愚にもつかないことです。
PostgreSQLの場合はそういったことは全くありません。よく、「PostgreSQLはWeb用と考えた方が良い。」なんていうのを雑誌でみますが、Webのようにクライアントが非常に多くても使用に耐えるわけで、クライアント10台、20台なんてわけなく処理する高性能データベースという捉え方が正しいのではないかと思います。Btrieveの時のデータを移管して、1年間分のデータが加わって今、104MByteあります。この位のデータなら最近はフラッシュメモリーでバックアップがとれます。
(実は、昨年の台風まではネットワークドライブだけにコピーをとり、フラッシュメモリーへのバックアップはとらなかったのですが、台風の時、停電、雨漏りでPCそのものを失ってしまいそうになり、フラッシュメモリーにもバックアップをとることにしました。アー恐ろし!)
PostgreSQLをインストールして使用の際にはチューニングは必須です。デフォルトは搭載しているメモリがかなり少なくても動作するような設定になっています。ソートでは使用するメモリ領域が広いほど速度が上がりますが、デフォルトでは大抵の場合、搭載したメモリが有効活用されていません。しっかりメモリを使いきるためにチューニングが必要です。
石井先生の「PostgreSQL完全攻略ガイド改訂第3版」でチューニングは一番後ろの方にあるので、見落としがちですが、これはどうしてもやらなければならないことです。私の場合、設定を変更することで、ソートなどは3倍程度速くなりました。
私が使用しているのはVer.7.3.5なのですが、postgresql.confの下記の項目を設定しました。
max_connections
shared_buffers
sort_mem
最近でたVer.8.0では名称が変わりました。
また、カーネルの設定変更も必要です。/etc/sysctl.conf で
shmall
shmmax
を設定し直しました。
詳しくはgooで検索してみるなり、マニュアルを見るなりしてください。
また、性能を維持するために定期的なvacuumが必要です。私の場合、週1回、psql から vacuum full; しています。
(削除された領域を再利用するためにはreindexしなければなりませんが、実際にはほとんど削除しないので、今のところreindexはしたことがありません。)
(ありがとうございます!)
もし、クライアントが2台以上あるなら、クライアント・サーバー型のデータベース構造にすべきです。(最近は3層構造なるものもあるようですが、良く知りません。) 私は、クライアントはAccessを使用してプログラムを作成していますが、Accessをデータベースとして使用しているわけではありません。給与計算ソフトはAccessをデータベースとして使用していますが、これは自分しか使用しないので特にクライアント・サーバー型にする必要はないと思っているからです。明細行も20人程度なので、月々20明細増える程度です。この程度ならAccessをデータベースとしても問題ないと思います。
PostgreSQLがなかったら自作はありえませんでした。以前はBtrieveを使用していたのですが、Btrieveと比べると多少重いかもしれませんが、非常に使い易いです。
「PostgreSQL完全攻略ガイド 石井達夫著」がよかったのか、セッティング、テーブルの作成変更、データのインポートなど非常に簡単でした。
BtrieveからPostgreSQLへのデータの移行はTakeMagic~Excel~Access+ODBCで行いました。まあ簡単です。
バックアップするにしても、Btrieveの時はサーバーにあるファイルごとバックアップをとっていました。(他にも方法があったのかもしれませんが、外注したベンダーからは「ファイルまるごとコピー」の方法しか教わりませんでした。)
PostgreSQLの場合はpg_dump というダンプコマンドからテキストファイルにしてバックアップをとります。バージョンアップの際もこのダンプデータをリストアすることで行います。作業的には簡単です。しかも、ダンプ時にロックがかかりません。ファイルまるごとコピーの場合はその間、データにアクセスするクライアントがあると、コピーは失敗してしまいます。
Btrieveの時は最終的にファイルの大きさが300MByteくらいありましたが(プログラムも含めて)、バックアップは結構大変な作業でした。挙げ句のはてに、コピー時にデータを失い、前日のデータに戻って改めてその日のデータを打ち直しすることが2回位ありました。データを失うというトラブルはその時しかありませんでした。安全のためにデータを保存する作業中にデータを失ってしまうという、愚にもつかないことです。
PostgreSQLの場合はそういったことは全くありません。よく、「PostgreSQLはWeb用と考えた方が良い。」なんていうのを雑誌でみますが、Webのようにクライアントが非常に多くても使用に耐えるわけで、クライアント10台、20台なんてわけなく処理する高性能データベースという捉え方が正しいのではないかと思います。Btrieveの時のデータを移管して、1年間分のデータが加わって今、104MByteあります。この位のデータなら最近はフラッシュメモリーでバックアップがとれます。
(実は、昨年の台風まではネットワークドライブだけにコピーをとり、フラッシュメモリーへのバックアップはとらなかったのですが、台風の時、停電、雨漏りでPCそのものを失ってしまいそうになり、フラッシュメモリーにもバックアップをとることにしました。アー恐ろし!)
PostgreSQLをインストールして使用の際にはチューニングは必須です。デフォルトは搭載しているメモリがかなり少なくても動作するような設定になっています。ソートでは使用するメモリ領域が広いほど速度が上がりますが、デフォルトでは大抵の場合、搭載したメモリが有効活用されていません。しっかりメモリを使いきるためにチューニングが必要です。
石井先生の「PostgreSQL完全攻略ガイド改訂第3版」でチューニングは一番後ろの方にあるので、見落としがちですが、これはどうしてもやらなければならないことです。私の場合、設定を変更することで、ソートなどは3倍程度速くなりました。
私が使用しているのはVer.7.3.5なのですが、postgresql.confの下記の項目を設定しました。
max_connections
shared_buffers
sort_mem
最近でたVer.8.0では名称が変わりました。
また、カーネルの設定変更も必要です。/etc/sysctl.conf で
shmall
shmmax
を設定し直しました。
詳しくはgooで検索してみるなり、マニュアルを見るなりしてください。
また、性能を維持するために定期的なvacuumが必要です。私の場合、週1回、psql から vacuum full; しています。
(削除された領域を再利用するためにはreindexしなければなりませんが、実際にはほとんど削除しないので、今のところreindexはしたことがありません。)