3

Como vocês esperam que o botão "Run" funcione em um editor SQL?

No desenvolvimento do LibreDB Studio, um dos nossos contribuidores voluntários levantou uma questão interessante sobre o comportamento de múltiplas instruções SQL quando o usuário clica em Run.

Em vez de simplesmente decidir internamente, queria ouvir quem realmente usa SQL editors no dia a dia.

Por exemplo:

CREATE TABLE test (...);

INSERT INTO test VALUES (...);

SELECT * FROM test;

Ao clicar em Run, o que você esperaria que acontecesse?

Algumas possibilidades:

  1. Executar todas as instruções

Run executa todo o conteúdo do editor
Run Selection pode ser usado quando você quer executar apenas uma parte

  1. Executar a instrução atual

Run executa a instrução onde o cursor está
Run All executa todo o conteúdo do editor

  1. A seleção tem prioridade

Sem seleção > executa a instrução atual
Com seleção > executa as instruções selecionadas
Run All fica disponível separadamente

  1. Outra abordagem :)

Também existem alguns casos interessantes quando há várias instruções.

Por exemplo: se eu executar as três instruções acima, vocês esperariam que elas fossem executadas dentro de uma transaction automaticamente, ou preferem que transaction handling seja sempre explícito?

Estou particularmente interessado em saber o que vocês já estão acostumados a usar em ferramentas como DBeaver, DataGrip, SSMS, pgAdmin, TablePlus, Toad, PL/SQL Developer, phpMyAdmin, etc.

Não estou procurando necessariamente qual seria a implementação "correta". Quero entender o comportamento que parece mais natural para quem usa essas ferramentas.

Se puderem compartilhar qual editor vocês usam e como o Run funciona nele, seria ainda mais útil.

A discussão original também está acontecendo no GitHub:

Source code: https://github.com/libredb/libredb-studio

Discussion: https://github.com/orgs/libredb/discussions/776

Carregando publicação patrocinada...
5

Já usei bastante SSMS e DBeaver e particularmente para mim, o modo que o DBeaver executa instruções é o melhor: Executar a área selecionada pelo cursor, se não selecionar nada executa a instrução da linha (ou até o ponto e vírgula mais próximo).

Se quiser executar tudo deve selecionar propositalmente tudo (só dar CTRL A).

No SSMS acontecia muito de eu estar num arquivo com vários comandos, e sem querer dar um F5 e não perceber que tinha um DELETE, UPDATE etc. escondido ali no meio.

1

Esse é um ótimo exemplo, obrigado por compartilhar.

Principalmente o caso do SSMS com DELETE ou UPDATE escondido no meio do arquivo. Esse tipo de situação é justamente o que torna essa decisão mais interessante do que parece à primeira vista.

Também é interessante ver que, para quem já está acostumado com o DBeaver, executar a instrução atual por padrão parece muito mais natural, e executar tudo exige uma ação explícita.

Vou levar esse feedback para a discussão no GitHub. Obrigado!

3

Acho que se eu estou digitando SQL na mão, eu provavelmente sei o que é transaction. E eu usaria se quisesse.
No máximo você aí deve executar as instruções na sequência. Acho que o software não deve inferir que o usuário quer uma transaction. Ele deve ser literal.

Já sobre o botão de run, ele deve executar tudo, ou o selecionado. Não inferir também que o usuário sabe que é onde o cursor tá.

Basicamente. Banco de dados é algo precioso demais pra gente deixar um software inventando moda. Melhor seguir o padrão.

Essa é minha opinião.

1

Faz sentido, obrigado por compartilhar sua opinião.

Essa parte sobre não inferir uma transaction é especialmente interessante. Também estamos tentando entender até onde o editor deve ser "literal" e até onde deve tentar adivinhar a intenção do usuário.

E sobre o Run, é justamente esse comportamento que estamos tentando validar com a comunidade: executar tudo por padrão e usar a seleção quando o usuário quiser executar apenas uma parte.

Vou acompanhar as respostas por aqui e levar o feedback para a discussão no GitHub.