@cevheri

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

SQLエディタで複数のSQLを実行するとき、どんな操作が理想ですか?

現在、LibreDB Studio というオープンソースのSQLエディタを開発しています。

開発中に、ボランティアのコントリビューターから「エディタに複数のSQL文が書かれている場合、ユーザーが Run を押したら何を実行するのが自然なのか?」という話題が出ました。

例えば、次のようなSQLを書いているとします。

CREATE TABLE users (...);

INSERT INTO users VALUES (...);

SELECT * FROM users;

ここで、ユーザーが何も選択せずに Run を押した場合、皆さんはどのような動作を期待しますか?


よくある考え方

カーソル位置を基準にする

  • カーソルがあるSQL文だけを実行する
  • SQLが長い場合でも、必要な文だけすぐ実行できる
  • 選択した場合は、その部分だけを実行する

エディタ全体を基準にする

  • 選択なし → エディタ内のSQLを上から順番に実行
  • 選択あり → 選択範囲だけを実行
  • 実際に何が実行されるのかを判断しやすい

操作を明確に分ける

  • Run
  • Run Selection
  • Run All

のように、それぞれの操作の意味を明確にする方法もあります。


ここで少し気になっていること

単に「どれが好きか」だけではなく、実際のSQL開発では次のようなケースがあります。

  • SQL文の途中にカーソルがあるとき、「現在のSQL文」をどう判定するのがよいか
  • セミコロンがないSQLや、編集中でまだ不完全なSQLをどう扱うか
  • 10個のSQL文を実行して、7個目でエラーになった場合にどうするか
  • 複数のSQL文を実行するとき、トランザクションをどのように扱うべきか
  • 複数のSELECTがある場合、それぞれの結果セットをどのように表示すると使いやすいか
  • キーボードショートカットはどのような操作体系が使いやすいか

私はこれまでDBeaver、DataGrip、SSMS、PL/SQL Developer、Toadなど、いくつかのデータベースツールを使ってきましたが、ツールによってかなり考え方が違うと感じています。

そこで、実際にSQLを日常的に書いている方に聞いてみたいです。

皆さんが普段使っているSQLエディタでは、どのような実行方法が一番使いやすいですか?

「この操作が好き」「この挙動は怖い」「こうなっていると助かる」など、実際の経験を教えていただけるとうれしいです。

このテーマについては、現在GitHubでも議論しています。興味があれば、こちらもご覧ください。

1 likes

すべてのステートメントを上から順に実行することを期待します。
複数のSQL文を書いている状況は多くの場合「スクリプトとしてまとめて実行したい」と考えられるためです。
これにはエディタの実装がシンプルになる(テキスト全体をそのままバックエンドに投げるだけ)という開発側のメリットもあります。

1Like

同じく、すべてのステートメントが順に実行されることを期待します。
作成したSQLをファイルにして、DBのコマンドラインツールに食わせて実行するときの動作と、同じであって欲しいからです。
よしできた、実行しよう、というときにカーソルの位置とか頭にない…。

ちなみに、ご存知だとはおもいますが、SQL Server Management Studioでは、原則、全ステートメント実行なのですが、選択・フォーカスがある場合、その範囲のみが実行されます。個人的にはこの挙動が好みですが、選択状態に関わらず全実行でも問題はないと思います。

1Like

選択なし → エディタ内のSQLを上から順番に実行
選択あり → 選択範囲だけを実行
……が感覚的に自然ですかね。
実行範囲を明確にしたいならば、選択なしは「実行するSQLがありません。SQLを選択してください。」と表示するのもありだと思います。

助かる機能としてはA5:SQLに実装されている機能ですが、
「where句無しでテーブル全体に対するupdate/deleteを実行しようとしています。本当に実行しますか?」
の確認が出てくれると、破滅的な操作に対して最後の防波堤になってくれることがあります。
普段そんなSQL実行しないので、この機能が邪魔になることも少ないですしね。

2Like

実際にはSQLエディタを使っていないので、あくまで理想的な挙動の話ですが下記のようになります。

  • 選択状態と実行対象状態は別で管理する
  • 入力されたSQL文はデフォルトで実行対象状態にしておく
  • RUNボタンを押されたら実行対象状態のSQL文は全て実行する
  • 実行されCOMMITされたSQL文は実行対象状態が解除される
  • 一文も実行対象がない状態ではRUNボタンを不活性化する

何故このような挙動かというと、SQL文を直書きして実行するような状況は下記のような作業を逐次的に内容を確認しながら行う場合がほとんどだからです。

  • SHOW TABLESやSHOW CREATE TABLEなどで変更対象を確認する
  • トランザクション開始
  • SELECTを実行して変更したい行を見つける
  • UPDATEやDELETEを実行する
  • SELECTを実行して変更内容を確認する
  • COMMIT/ROLLBACKを行う

スキーマの初期化や大規模なテーブルの修正は、ORMを介して作成したDDLスクリプトをテスト環境で動作を確認してからそのまま流し込みますから。
なので、SQLエディタをもし使うなら「どこまで実行したのか」「実行結果や発生したエラーはどうだったのか」「どんなSQL文を実行したのか」が分かるようになっていてほしいですね。

1Like

A5:SQL Mk-2 だと次の選択肢がありますね。
image.png

  • プロシージャモード
  • キャレット位置
  • キャレット位置以降
  • 先頭から全て

私は必要に応じて選択して実行するのでキャレット位置 派です。

1Like

自分はHeidiSQLとmariadbをよく使用していて、
同じようにSQLEditerがあればどのような操作性が理想かを考えることがよくあります。

まず質問に端的に回答すると、issuesにもあるようにRunボタンを押した時の動作としては上から順番に実行されることを望みます。

選択しているSQLのみが実行されるのであれば、イメージでは拡張機能的な動きに思えるので、拡張機能をインストールすることで使えるとかで私の場合よいです。

それでももし、本体に入れたいのであれは選択範囲を実行するというボタンをつけるべきだと思います。
私がHeidiSqlをよく使用するからか分かりませんが、UI上のボタンよりはコンテキストメニューで実行を押せた方が便利だと感じるため、そこに入れるのが操作上のストレスもないかと思います。

そしてお世話焼きかもしれませんが、
このアプリでユーザーが何をしたいのかを整理した方がより直感にあった操作の設計判断ができるのではないかなと思いました。
1度検討されたでしょうが、個人的には選択範囲のSQLを実行するのはRunというよりExecuteです。

実は私も同じようなアプリを作成していますが、私のアプリではSELECTしか保証しません。
実行するクエリのautocommitをfalseに設定し、全ての処理が終わったらrollbackします。

もし安全を考えるのであれば、このモードをexecuteQueryのように配置して見てもいいと思います。
より安全で何が行われるのか明確です。
もし、insertやcreateをしたい場合ユーザーは別のボタンを探すでしょう。

また、選択範囲だけが実行されるのが非直観的な理由として、logかコンソールかに、実行したSQLを書き込んでいくようなviewがあるか、これから増えるかするでしょうが、
実行したSQLとエディタを見比べた時に認知的な不和が起きることと、
もう1つはトランザクションのようなステートメントを意図的に実行したい時に、ユーザーにとっては挙動が読めず逆に危険な操作になってしまう為です。

ちなみに自分はHeidiSqlでほとんどの操作は足りるため、SQLクライアントを作る構想は捨てました。
今は.sqlファイルをフォルダから読取SQLの結果をシートごとに分けてExcelに吐き出す単純なアプリを作っています。

1Like
This answer has been deleted for violation of our Terms of Service.

Your answer might help someone💌