Accessでデータベースに初めて触れる、という方が多いのかもしれないので、Accessのテーブル定義で気をつけておかないといけないことを項目だけでも最低限挙げておく。先にはもう少し丁寧に解説するかもしれない。




・どの型を使うのが望ましいのか


・文字型の文字数は全角なのか、半角なのか(型による限界値)


・キー、インデックス


・NULLと空文字の違い




上記のうち「それ何?」と言うようではまずい。


知らなくても使っている方もいるだろう。しかしそういう方は「データベースを知らずにAccessでシステムを作っている」という、非常にリスキーなことをしているのだ。




書きたいことはたくさんあるが、今のテーマからそれるのでこのくらいにしておく。




そこかしこで空き放題SQL文を書いているようでは、修正が入った時に影響度合いの調査に非常に骨が折れます。また、テーブル定義を変更した時も結構面倒です。メリットはありません。




データへのアクセスするSQL文は、クラスモジュールで集中管理しましょう。1テーブル1クラスが理想でしょう。




そのクラスモジュールを検索すればアクセス状況が良く分かりますし、似た処理なども集中管理できます。




クラスモジュールの使い方は少し敷居が高い部分でもあります。


簡単に言うと、


・使う時に生成する(New)


・使い終わったら捨てる( = Nothing)


・他のクラスモジュールの プロシージャ名、ファンクション名と同じ名前を付けて大丈夫なので類似処理は同じ名前を付けておける。


などですが、一般的なオブジェクト指向言語のクラスとは異なり


・継承ができない


など不便な点もあります。




しかし、クラスモジュールを使えるようになると格段にコードの質がアップするので、是非ご理解いただきたいところです。




Accessには同じことをしようとするのに複数の手段があります。


フォームの作成に関して、メニューから作成するものとVBEから作成するものがある。


  ※これについて最近調べると、Access2000以降ではないようです。97時代の記憶だったかもしれません。


・データベースへの操作に関して、クエリ、VBAのコードから可能である。


・処理はマクロでもVBAでも書ける。(書けるレベルは違いますけれど)


等です。




これ、適当に混在させるとものすごくわけわらんコードになってしまいます。




可能な限り揃えましょう。VBAベースで開発するのであれば


VBEからのフォームを使う。


  ※これについて最近調べると、Access2000以降ではないようです。97時代の記憶だったかもしれません。


・DB操作はVBAから、それもDAOやADO経由でSQLを使って操作する。


・処理はVBAで書く。


を推奨します。




なぜか、というと「VBAに記載しておけば検索ができる」ので、後々調べるのがうんとラクになるのです。


また、間違って削除クエリなんて押してしまった日にゃあ、っていう事故も防げます。




市販本では「あるものは全部解説」の傾向にあります。素人がシステムを作るには敷居は低くなっており、そういうニーズには応えて伊入るとは思うのですが、業務として使うのであれば、保守性の面から使わない方がいい機能もあります。上記はその代表例かと存じます。