最近、ちょっとしたツールの作成にAccessを使いだしています。Accessといえば開発入門の時によく使っていましたが、仕事として業務システムを開発するには危なっかしいイメージがあり採用することはほとんどありませんでした。
今回、利用者１名でExcel管理に毛の生えたようなレベルのツールを作るためにAccess採用。作っていくうえでオブジェクトが増えすぎて煩雑になってきたので自戒の意味も込めてAccessを使う上での整理ポイントについて個人的な考え方をまとめておきます。
なお、ちゃんとしたシステムであれば、画面遷移図やら各種オブジェクトの一覧、設計書なども作るでしょうし、各種命名規約もきちんとしていると思いますので、今回のケースはそんなきっちりしないで「ざっと」作るときにでも注意しておいた方がいいですよ。というレベルの情報です。
【登場人物】
Access データベースファイル
フォーム、レポート、テーブル、VBAプログラム、マクロ
【これをやっておけば何とかなる】
命名はきちんとね。
【整理せずに進めて困る可能性がある事例(やらかしたこと含め)】
・テーブルの分類が不明
マスタなのか、トランザクションなのか、ワークなのか
・フォームの用途が不明
入力フォームなのか、処理フォームなのか、サブなのか
・レポートの呼び出し元が不明
単体で呼び出せるが
・活きているオブジェクトなのか、試作なのか不明
・そもそもソース管理が
【これだけはやっておこう】
テーブル
接頭語くらいはつけましょう。必ず「作るときに実施」後で変えてもAccessが良きに計らってリファクタしてくれるようですが、してくれない箇所もあります。（ソースへの記載は当然ながら変えてくれません）
フォーム
ある程度のカテゴライズは事前にしておきましょう。考えられるカテゴリとしては
メニュー：画面遷移だけするもの
入力フォーム：データの登録、修正するもの
サブフォーム：入力フォームの中に組み込むもの
サブ画面：入力フォームのサブ機能をもつもの、処理指示など
個人的にはいわゆる「接頭語」と連番でまとまるのが良いと考えてます。
例) xxxxはわかりやすい日本語名
メニュー：FM連番xxxxxxx
入力：FI連番xxxxxx
サブフォーム：FI連番SUB連番xxxxxx
サブ画面：FS連番xxxxx
クエリ
作成する数も多いのでこれが一番散らかります。【決めごと】
画面、レポートなどのオブジェクトに対応するものは同じ接頭語をつける。その後に詳細用途
例)
FI連番SxxxxxxForm
FI連番Sxxxxxxcboxxx ※セレクトボックス
FI連番SxxxxxxListxxx
FI連番Ixxxxxxx (Insertクエリとか)
FI連番SxxxxxxXXXXQuery
長くなっても、用途がわかった方が良い
共通はCOMxxxとかでいいんじゃないかな。
間違っても、日本語名だけではやらないこと。絶対にあとでわからなくなります。
クエリのネスト
クエリでクエリを参照することはあると思いますが、その時に命名をどうするかは悩ましい。私の場合には１処理でネストする場合のみSub1,Sub2とかで命名します。
既にあるフォームで作成しているクエリを参照したい場合、面倒であっても
作成済みクエリを直接参照するのではなく、新規クエリで作成済みクエリを参照するようにしています。
レポート
ID命名と、メインかサブかがわかればよいのではないでしょうか。フォームから呼ぶのであればフォームと同じ連番をつけておけばOK
マクロ
個人的にはあまりなじみがありませんが、連番が合っていれば間違えないかと。VBA
いわゆる個別処理か、共通処理かでモジュールは分けると思いますのであとは一般的なコーディング規約でいいのではと思います。
まとめ
だらだらと列挙しましたが、結局のところ「命名」に尽きると思っています。
後で見た時、またはほかの人が見た時に相関性がわかるのが重要ですね。
余談
私の場合、ある程度作り込んだ後はデータとプログラムのファイルを分けてます。プログラムのファイルからデータのファイルへリンクを張ることで実現。
プログラム改修などの際にはプログラムファイルだけを更新すればよいため利便性が高いです。
