Accessについてわーっと書きたくなった

昨日Instagramで、おれがクリスマスの夜に凍死しても、マッチ売りの少女やネロとパトラッシュみたいにはならず、『シャイニング』のジャック・ニコルソンみたいにしかならんと投稿したら、俄然『シャイニング』が見たくなった。
で、今朝Amazon Primeビデオで『シャイニング』のラストをちょっと見た。ジャック・ニコルソンの凍死シーンが役者的に羨ましい。白目はこういう時にむきたいものだ。

新ツールのテストと修正進める。かなり細かい部分まで突っ込んで修正し、かつコードもシンプルにしたので、運用が始まるのが楽しみになりつつある。

昼、『PIT』でラーメン。野菜増し。

Accessについてわーっと書きたくなった。

Accessのリンクテーブルをほとんど使わない。遅いし管理が面倒くさい。
特にバックエンドにデータを保存し、複数名でクライアントDBにデータアクセスする時、人が増えると速度が急低下する。フォームを開く時など顕著でそのまま固まってしまうこともある。これはリンクテーブルにを開く前にバックエンドDBとクライアント間に通信が行われるためらしい。
速度対策のため何も保存してないテーブルをダミーとしてバックエンドに置き、クライアントで最初にダミーテーブルのリンクテーブルを開き、そのあとで目的のフォームを開く運用にすると、最初の通信時間が短縮されフォームがすぐに開くようになる。しかし、なんでわざわざそんな手間をかけなきゃいかんのだ、と思う。
自分はかれこれ十年以上、SQLにバックエンドDBのフルパスを記載した選択クエリを使っている。
たとえば T_会員情報 とかいうテーブルがあるとして、そいつがネットワーク上の \\net001\管理DB.accdb という Access に保存されていたとする。するとクライアントツールに T_会員情報 という同名のクエリを作成し、SQLにこう書く。
SELECT * FROM T_会員情報 IN '\\net001\管理DB.accdb'
パスワードがある場合はこうかな。
SELECT * FROM T_会員情報 IN '' [MS ACCESS;DATABASE='\net001\管理DB.accdb';PWD=なんちゃら]
リンク先を変更する場合は、'' で区切ったフルパスを変更すれば良いだけなので、保存先やパスワードを引数にしたそれ専用の関数を作っておけばいい。こうしてできた T_会員情報 クエリは、テープルと同じように使える。
ただしTransferSpreadsheet などを使ったインポート先には使用できない。クエリだから。しかしバックエンドに置いたテーブルに直接そうやってインポートするなんてことはないと思うが。
リンクテーブルを使用したシステムの場合、フォームによるデータロック設定がかかっていないことも多かった。そういう時は疑似ロックをするよう運用されていた。でもやっぱり複数名運用の場合は編集済レコードのロックをかけた方が安定度は高まる。昔、一日に何回データベースが壊れるかを毎日数えて記録していたが、リンクテーブルを廃止して上記のクエリ接続運用にし、編集済みレコードレベルのロックをかけるようにしてからは、ネットワーク遅延などの理由以外ではまったく壊れなくなった。
ただ、Access2007以前のmdb時代より、accdbの方が速度アップは緩やかだ。というより、accdbのリンクテーブルは昔より早いのかもしれない。
バックエンドDBに保存するテーブルの目的と負荷についてもじっくり考えた方がいいと思う。ログのように一方的に追加し続けるテーブルと、データのやり取りを頻繁にするテーブルは、同じDBに保存してはいかん。データのやり取りを頻繁にするテープルと、案件がクローズしたテーブルを別DBに分けるだけでも、ツールのパフォーマンスはアップする。バックエンドDBは、生きたデータ、アーカイブ、マスタの三種類あるといいかなあと思う。
マスタDBにはマスタテーブルやバージョン管理用のテーブルを置き、起動時にそこから都度クライアントにコピーする運用にすれば便利だ。時々マスタテーブルをリンクテーブルにしているツールがあるが言語道断。そんなテーブルでクエリを作ったら破壊的に遅く重く不安的になる。
ユニオンクエリもただUNIONしただけのやつがあったりするが、一つ一つのテーブルなりクエリなりにきちんとWHERE条件をつけて最後にUNIONせんといかんよなあと思う。ここに気をつけると重い重いといわれるUNION文もなかなか使い心地が良くなる。
ステータスは、フィールドのステータスなのか案件全体のステータスなのかをきっちり区別しないといけない。そして案件全体のステータスは値である必要はない。のだけどやっばり値にしちゃう。リンダ困っちゃうみたいな気分で。
AccessのSQLビューは使いにくい。そしてデザインビューにしてちょっと変更するとSQL文が別の物に成形されてしまう。なので直でSQLを書く時はテキストエディタに書いて貼り付けるようにしている。実際、直で書いた方が処理を一つ一つ検証しやすい。
悩みどころはトランザクション処理だろうか。サーバーに SQL Server がインストールされているみたいなのではなく、ただデータを置いてるというだけだし。無理なんだろうなあ。疑似トランザクション用のデータベースをどっかに置き、変更削除のミラーデータを置くとか？ 超面倒くさい。
とはいえ、リンクテーブルを使わず、バックエンドDBの種類に気をつけてデータ置き場を整理すると、50万件くらいまで普通にサクサク運用できていた。50万件常にしょっちゅうアクセスすることはないし。日々の運用でデータ変更を行うのはせいぜい数万件くらいだし。同時使用者が増えても、対象テーブルが軽いとそんなに重くはならなかった。逆に同時使用者が5人に満たなくても、対象テーブルが5万件以上あると急に重くなった。その5万件も、うち4万数千件は完了済データだった。

書いた書いた。ストレス解消。

6時半帰宅。げげっ、クリスマスイブじゃん。丸ごとバナナに仏壇用ローソクをさして祝わないとと思ったが、丸ごとシリーズは帰りに寄ったオーケーストアじゃ売り切れていた。なのでケーキなしのクリスマスイブ。チキンもなくなぜか冷しゃぶサラダを作りそれで祝った。白ワインと生牡蠣を食べた。