1
4
Accessでツールを開発する時の、データ抽出,更新,挿入,削除などの処理をする時の、SQL文とクエリの使い分けについて、開発に携わっている方がどうされているのか教えてください。
SQL文を自分で作成してもクエリデザインで作成しても同じ結果を得られると思いますが、皆さんはどちらを使用して開発をされていますでしょうか。
※例えば特定のテーブルのデータを抽出する時、
VBAのコード内にSQL文(sql = "SELECT * FROM tbl_emp;")を作成し、それを実行してデータを取得する方法と、
Access内のクエリデザインなどであらかじめ作成しておいたクエリをコード内で実行しデータを取得する方法があると思います
トランザクションが必要な処理はクエリを使用しないのはわかります。
もしトランザクションが必要で、その部分の処理SQL文で作成した場合、
そのほかの処理もクエリを使用せずに作成してしまった方が、後でソースコードを読み返す時、モジュールとナビゲーションウインドウのクエリを行ったり来たりせずに済むのではないかと思ってみたり、
はたまた、クエリを使用して開発して方が早いし楽なのかなと思ってみたりしています。
また、SQL文とクエリが混在するのにも若干の違和感があったりするのですが、そこは気にしなくてもよいのでしょうか。
みなさんは、どのようにされていますか？
また、使い分けの明確な基準はお持ちですか？
クエリしか使用しないまたは、SQLしか使用しないという方はいらっしゃいますか？
回答13件
#1
総合スコア894
投稿2023/03/20 07:48
SQL文を自分で作成してもクエリデザインで作成しても同じ結果を得られると思いますが、
皆さんはどちらを使用して開発をされていますでしょうか。
それぞれの処理の目的と難易度、他のオブジェクトとの結合度、
可読性やメンテナンスのしやすさなどに応じて、どちらも使用します。
トランザクションが必要な処理はクエリを使用しないのはわかります。
（何故そのような認識をされているのかが不明ですが）
トランザクションが必要な処理でもクエリを使用することは可能です。
もしトランザクションが必要で、その部分の処理SQL文で作成した場合、
そのほかの処理もクエリを使用せずに作成してしまった方が、後で
ソースコードを読み返す時、モジュールとナビゲーションウインドウの
クエリを行ったり来たりせずに済むのではないかと思ってみたり、
例えば 3 つ以上のテーブル同士を結合させたり、それらの中に
「 3 つ以上のフィールドで主キーが構成されているテーブル」が
含まれているなど、複雑な SQL を記述しなければならないケースを想像し、
そのメリット/デメリットについて検討してみるとよいのではないでしょうか。
少なくとも「選択クエリを作っておかないとやりにくい処理」というのはあります。
（選択クエリをエクスポートしたり、外部プログラムからクエリを参照する場合など）
はたまた、クエリを使用して開発して方が早いし楽なのかなと
思ってみたりしています。
また、フォームから行われた入力操作に応じてSQLを動的に生成する
（と共に、QueryDefオブジェクトのSQLを書き換える）ことが
要求されるケースもあるでしょう。
また、SQL文とクエリが混在するのにも若干の違和感があったりするのですが、
そこは気にしなくてもよいのでしょうか。
違和感があるのは「できればどちらかに統一したい」という意図が働いているからだと
思われますが、まずそう思われた理由や根拠を具体的/論理的に説明できなければ、
それは個人の主観や好みの域を出ないでしょう。
#2
総合スコア25279
投稿2023/03/20 07:56
編集2023/03/20 08:13基本的にSQLですね。
クエリーでないと駄目だったりするケースの場合はSQLでクエリーを定義します。
SQLにする一番の理由は、俯瞰できる様にする事です。
そういった意味では、SQLに限らずデザインに埋め込むようなものもコードで設定するようにします。
クエリーを使うのは、クエリービルダでは表現できないSQLもあるので、データの確認や補正などの一時的な用途くらいですね。
クエリービルダはAccessだけが持っている機能ではありませんし、一般的にはDB操作の初歩としてクエリーがあるというイメージですね。
結局扱う人のスキル次第じゃないでしょうか。
マクロにするのかVBAで記述するのかというのと似ているように思います。
#4
#2 saziさま
ご回答ありがとうございます。
saziさまは基本的にSQLなのですね。
開発は主にSQLで行い、データの確認用としてクエリを使用するという方法もあるのですね。
<<SQLにする一番の理由は、俯瞰できる様にする事～
というのは、以下の理解で合っていますでしょうか？(違っていたらすみません。。。)
・ソースコードの中でデータ処理の部分(SQL)も確認できる(クエリの中身を見に行かなくて済む)
・フォームのラベルやボタンの内容などを条件によって切り替える
追記にありました下記、確かに納得できます。
<<結局扱う人のスキル次第じゃないでしょうか。
<<マクロにするのかVBAで記述するのかというのと似ているように思います。
#5
総合スコア25279
投稿2023/03/20 08:39
編集2023/03/20 08:40#4 maru3 さん
そもそもAccessはデータベースの扱いについての敷居を下げる位置付にあります。
そういう意図に則るとクエリーを使用するというのは当然ですね。
ただ、それが積み重なって規模が大きくなると、保守が辛くなります。
そうならないようにするには可読性を高める必要があり、クエリーを使わないというのもその選択肢です。
#7
総合スコア34017
投稿2023/03/21 03:13
編集2023/03/21 05:55開発者のスキルや開発方針によると思いますが、私の場合は基本はクエリです。
Accessが開発するということはUI部分はフォームやレポートが受け持つことになります。フォームやレポートはテーブルやクエリと連結することになります。
連結する場合、レコードソースにテーブル/クエリまたはSQLを設定することになりますが、基本SQLは設定しません。
クエリはリレーションシップに基づいて各テーブルを結合するシンプルなものにしておいて抽出条件や並べ替えは設定しないようにします。
抽出条件や並べ替えはフォームやレポートのFilterやOrderbyで設定するようにします。
グループ化はフォームならメイン/サブフォーム形式、レポートならグループ化/集計機能を使います。
集計結果も基本クエリから集計クエリ、クロス集計クエリなどを作成します。
基本クエリをフォームやレポート、集計クエリなどで使いまわせるような設計を心がけます。クエリが増えすぎると保守が困難になりますので、なるべくクエリは増やさずに使いまわせるようにするということです。
どのテーブル/クエリでどこ(フォーム、レポート、集計クエリ)で使わているかという関係は命名規則を工夫することである程度は管理でます。規模が大きくなるなら構成図は必要ですが、それさえ作っておけば保守はそれほど困りません。
SQLを使う場面としては、データを一気に更新したりするときか、フォームやレポートの機能では対応できない場合ですがめったにないですね。その場合も一からSQLを書くのではなく、クエリを基にしたSQLの場合が多いです。
#8
総合スコア170
投稿2023/03/21 04:01
クエリです。SQLにする必要があれば、他に乗り換えます。
つまり、クエリとSQLの使い分けは、どこまでAccessでやるのか、AccessでSQLをやる必要が本当にあるのか、です。
#9
#7 hatena19さま
ご回答ありがとうございます。
hatena19さまは基本的にクエリなのですね。
<<開発者のスキルや開発方針によると思いますが～
確かに私もそう思います。そうですよね。
<<クエリはリレーションシップに基づいて各テーブルを結合するシンプルなものにしておいて～
こちらとても納得しました。確かに1つのクエリに色々な条件を入れてしまうと、
それ専用になってしまい使いまわしが出来ないので、クエリの数が増える原因になりますね。
少し前に他人が作成したものを直す機会があったのですが、クエリが200個くらいありまして、
今思えば使いまわしのきかない、その処理専用のクエリばかりだったと思います。
使いまわしができるクエリを作成することが大切だと再度認識しました。
勉強になりました。
ありがとうございました。
#11
総合スコア957
投稿2023/03/22 09:48
自分で１から構築するならSQLでやりますが
実際に１からやったことはありません。
底知れぬ過去の遺産のメンテナンスが主でしたので
SQLとクエリが入り混じったものと戦ってきました。
私がSQLで行う、と考えるのは
保守時にクエリの中身を開いてSQLを確認するのが手間と感じてたからです。
過去にSQLステートメントの文字数制限にひっかかり
文字数を節約するためにしぶしぶ内部のサブSQL文をクエリ化したことがあります。
ここまで規模が大きくなれば
他の回答にもある通り別のプラットフォームに乗り換えるべきなんだと思います。
#13
総合スコア11
投稿2023/03/28 05:08
クエリはAccessで開発するメリットの一つでもあると考えていますので、#8 logres_Fanさんと同意見となります。
ただし、SELECT系のみで、INSERT、UPDATE、DELETEはすべてSQLで実行するようにしています。
クエリだと何かの拍子で意図せず実行してしまうことがありましたので、それ以降データ更新系はSQLで実行するようにしています。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。