最近、販売管理システムの引継ぎをしている。
実務としてはAccessのプログラム廻りばかりの作成や修正ばかりやっていたので、
PostgreSQLの勉強は全くしていなかったし、SQLについてもAccessのクエリービルダーで
作っていたので、SQLもほとんどわからない状態だった。
担当者がSQLの勉強をしていて、本に書いてある用語を言われてもわからなかったり、引継ぎするのにさすがに恥ずかしいので、長い盆休みもあり少し勉強した。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 (Software Design plus) 単行本（ソフトカバー） – 2022/11/26
上原 一樹 (著), 勝俣 智成 (著), 佐伯 昌樹 (著), 原田 登志 (著)
PostgreSQLもYouTubeに色々解説動画があって、勉強になった。
いい時代になったもんだ。
2003年から運用して当時PostgreSQLのバージョンが7.4?だったか、自動vacuum機能がなくて、夜12時にvacuumするスクリプトを書いたような記憶がある。そんなこともあったけど、最近 vaccum fullするのをすっかり忘れていた。もう、何年もやってない。これまでのサーバーの不具合はvacuum full してなかったからだろうか？
これから１ケ月に１度は忘れないで実行しよう。
pg_hba.confの設定もまずかったので修正。postgrsql.confの設定もPCが高機能化しているのに、従来の設定のまま使っていた。shared_buffesの設定を4GBに修正してヒット率が今のところ92%から95%に上がった。（変更後4週間で97%まで上昇)
統計情報が徐々に更新されているので、最終的にどのくらいまで上がるか様子見中。
どのクライアントもスーパーユーザで使っていたけど、ロールも修正予定。
やっぱり、勉強は必要だなと実感。
バックアップ。
毎日、論理バックアップを取ってる。また、昔は「同時に３ケ所に保存」って言ってたので、サーバー、クライアント、USBと３ケ所同じデータを保存している。クラッシュした時、一番、現状復帰に近い状態にするためにはWALの保存と、物理バックアップを取っておかなければならないようだけど、WALの保管は容量が大きく管理が大変そうなのであまり気が進まない。
事務所が使っているデータは必ず紙データが残っているので、昨日のバックアップデータから復旧するのはそれほと難しくない。
PostgreSQLになってクラッシュしたことは一度もないのだが、以前、Btrieveを使っている時、データを壊してしまったことがある。それもバックアップ最中に。
Btrieveは使用中、物理バックアップがとれないのでクラアントを止めてもらってバックアップしていたのだが、マウス操作（当時はボール式）ミスでデータを無くしてしまった。
クラッシュに備えてバックアップ取ってるのに、バックアップ中にデータ壊してしまうなんて本末転倒。そんなことがあったので、あまりゴチャゴチャ、バックアップ作業をする気にならない
PostgreSQLの論理バックアップは使用中でもバックアップ取れるので、簡単。容量が11GBくらいになったので、zip（容量4GB、圧縮率87%になる）してそれぞれに保管している。
zip化してpg_dumpもできるようなのだが、デバッグをWindows版のPostgreSQLでやっていて、クラアントに保管したバックアップデータをWinodowsで展開後、Windows版PostgreSQLにリストアしている。なので、Linuxでも手動でzipした方がその後が楽。
（「デバッグ中のデータを壊した」という失敗例がデータベース本の例え話で書いてあることがあるが、
insert、update、deleteがからんだデバッグは絶対に本機ではやらない。なので、Winodows版ではあるが、リストア作業を日常的にやってる。dropdb、createdb、pgsql、まあ簡単な作業なんだが。）
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ
ミック (著)
中小企業向けAccess開発実践ノウハウ 単行本 – 2007/1/1
前野 好太郎 (著)
SQLでこんなことまでできるのかとビックリ。
だけどやっぱり、フロントエンドとしてのAccessは最高の開発環境だと思った。
これまで、「クエリーのネスト（入れ子構造）」を常態的に使ってきた。
複雑な集計もクエリーを組み合わせて作成した。
「Access開発実践ノウハウ」だと「必ずしも偏見を持たないで使ってもいいか！？」ということだけど、そんなこと全く知らないで使っていた。確かに修正がし辛い面はあるけど、長く難しいクエリーを書いてもやっぱり修正は難しいだろう。「入れ子構造」だと名前付けを工夫さえすれば、クエリーが分解されている分、まだましかもしれない。
集計クエリーがらみでAccessにないPostgreSQLの便利な関数を使ってパススルークエリーすれば、簡単に集計できるのかもしれないが、こういった場合はあっさりPostgreSQLにviewを定義してAccessのリンクテーブルとして参照してきた。なので、パススルークエリーはほとんど使ってない。
大抵、こういった集計は売上資料（レポート）のソースとして使うので、リンクテーブルにしたおいた方が楽だ。
Accessのクエリーの組み合わせで難しい場合は、Accessにレポートソース用のテーブルを作っていた。このやり方にしても、Accessがデータベース機能を持っているからできる。Accessにデータベース機能がなければ、PostgreSQLにテンポラリーテーブルを作って、レポートソースにすることになるだろうけど、共有しているサーバーに負荷をかけたくない。使用後は削除してしまうわけだし、クライアントごとにテーブル名を決めなければならないのもいやだ。クライアント側でテンポラリーテーブルを作成できるのもAccessのいいところだ。
実務としてはAccessのプログラム廻りばかりの作成や修正ばかりやっていたので、
PostgreSQLの勉強は全くしていなかったし、SQLについてもAccessのクエリービルダーで
作っていたので、SQLもほとんどわからない状態だった。
担当者がSQLの勉強をしていて、本に書いてある用語を言われてもわからなかったり、引継ぎするのにさすがに恥ずかしいので、長い盆休みもあり少し勉強した。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
［改訂3版］内部構造から学ぶPostgreSQL―設計・運用計画の鉄則 (Software Design plus) 単行本（ソフトカバー） – 2022/11/26
上原 一樹 (著), 勝俣 智成 (著), 佐伯 昌樹 (著), 原田 登志 (著)
PostgreSQLもYouTubeに色々解説動画があって、勉強になった。
いい時代になったもんだ。
2003年から運用して当時PostgreSQLのバージョンが7.4?だったか、自動vacuum機能がなくて、夜12時にvacuumするスクリプトを書いたような記憶がある。そんなこともあったけど、最近 vaccum fullするのをすっかり忘れていた。もう、何年もやってない。これまでのサーバーの不具合はvacuum full してなかったからだろうか？
これから１ケ月に１度は忘れないで実行しよう。
pg_hba.confの設定もまずかったので修正。postgrsql.confの設定もPCが高機能化しているのに、従来の設定のまま使っていた。shared_buffesの設定を4GBに修正してヒット率が今のところ92%から95%に上がった。（変更後4週間で97%まで上昇)
統計情報が徐々に更新されているので、最終的にどのくらいまで上がるか様子見中。
どのクライアントもスーパーユーザで使っていたけど、ロールも修正予定。
やっぱり、勉強は必要だなと実感。
バックアップ。
毎日、論理バックアップを取ってる。また、昔は「同時に３ケ所に保存」って言ってたので、サーバー、クライアント、USBと３ケ所同じデータを保存している。クラッシュした時、一番、現状復帰に近い状態にするためにはWALの保存と、物理バックアップを取っておかなければならないようだけど、WALの保管は容量が大きく管理が大変そうなのであまり気が進まない。
事務所が使っているデータは必ず紙データが残っているので、昨日のバックアップデータから復旧するのはそれほと難しくない。
PostgreSQLになってクラッシュしたことは一度もないのだが、以前、Btrieveを使っている時、データを壊してしまったことがある。それもバックアップ最中に。
Btrieveは使用中、物理バックアップがとれないのでクラアントを止めてもらってバックアップしていたのだが、マウス操作（当時はボール式）ミスでデータを無くしてしまった。
クラッシュに備えてバックアップ取ってるのに、バックアップ中にデータ壊してしまうなんて本末転倒。そんなことがあったので、あまりゴチャゴチャ、バックアップ作業をする気にならない
PostgreSQLの論理バックアップは使用中でもバックアップ取れるので、簡単。容量が11GBくらいになったので、zip（容量4GB、圧縮率87%になる）してそれぞれに保管している。
zip化してpg_dumpもできるようなのだが、デバッグをWindows版のPostgreSQLでやっていて、クラアントに保管したバックアップデータをWinodowsで展開後、Windows版PostgreSQLにリストアしている。なので、Linuxでも手動でzipした方がその後が楽。
（「デバッグ中のデータを壊した」という失敗例がデータベース本の例え話で書いてあることがあるが、
insert、update、deleteがからんだデバッグは絶対に本機ではやらない。なので、Winodows版ではあるが、リストア作業を日常的にやってる。dropdb、createdb、pgsql、まあ簡単な作業なんだが。）
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ
ミック (著)
中小企業向けAccess開発実践ノウハウ 単行本 – 2007/1/1
前野 好太郎 (著)
SQLでこんなことまでできるのかとビックリ。
だけどやっぱり、フロントエンドとしてのAccessは最高の開発環境だと思った。
これまで、「クエリーのネスト（入れ子構造）」を常態的に使ってきた。
複雑な集計もクエリーを組み合わせて作成した。
「Access開発実践ノウハウ」だと「必ずしも偏見を持たないで使ってもいいか！？」ということだけど、そんなこと全く知らないで使っていた。確かに修正がし辛い面はあるけど、長く難しいクエリーを書いてもやっぱり修正は難しいだろう。「入れ子構造」だと名前付けを工夫さえすれば、クエリーが分解されている分、まだましかもしれない。
集計クエリーがらみでAccessにないPostgreSQLの便利な関数を使ってパススルークエリーすれば、簡単に集計できるのかもしれないが、こういった場合はあっさりPostgreSQLにviewを定義してAccessのリンクテーブルとして参照してきた。なので、パススルークエリーはほとんど使ってない。
大抵、こういった集計は売上資料（レポート）のソースとして使うので、リンクテーブルにしたおいた方が楽だ。
Accessのクエリーの組み合わせで難しい場合は、Accessにレポートソース用のテーブルを作っていた。このやり方にしても、Accessがデータベース機能を持っているからできる。Accessにデータベース機能がなければ、PostgreSQLにテンポラリーテーブルを作って、レポートソースにすることになるだろうけど、共有しているサーバーに負荷をかけたくない。使用後は削除してしまうわけだし、クライアントごとにテーブル名を決めなければならないのもいやだ。クライアント側でテンポラリーテーブルを作成できるのもAccessのいいところだ。