20 pontos por xguru 2025-01-24 | 8 comentários | Compartilhar no WhatsApp
  • Ferramenta de gerenciamento de banco de dados leve, com menos de 20 MB, mas poderosa e amigável ao usuário
    • PostgreSQL, MySQL, SQLite3, MongoDB, Redis, MariaDB, ElasticSearch
  • Permite consultar e gerenciar dados em linguagem natural em vez de escrever SQL complexo: integração com Ollama, ChatGPT e Anthropic
  • Suporte à virtualização de tabelas no frontend
  • Visualização do esquema do banco de dados em gráfico
  • Edição direta (inline) de dados e pré-visualização de resultados na interface
  • Scratchpad: interface de consulta a banco de dados no estilo Jupyter Notebook
  • Desenvolvido em Go, é rápido e pode ser instalado facilmente com Docker
  • Relação com outras ferramentas
    • Desenvolvido com o objetivo de ser uma ferramenta inspirada no Adminer, reforçando a UX e a visualização de dados com base em leveza e facilidade de uso
    • Enquanto o DBeaver oferece muitos recursos, mas exige mais recursos do sistema, o WhoDB é leve, eficiente e funciona bem mesmo em ambientes menores

8 comentários

 
bungker 2025-01-24

O prompt está definido aqui: https://github.com/clidey/whodb/blob/main/core/src/common/chat.go Os comandos por linguagem natural foram implementados em um nível realmente bem simples.
Conectei com o ollama phi4, montei uma configuração básica de DB e testei alguns comandos; uns 10 comandos foram executados corretamente. Nem sei quem deveria receber o elogio aqui.

 
savvykang 2025-01-24

Usei a demo e vi vários pontos que precisam de melhoria. Para se autodefinir como poderoso, ainda parece faltar bastante caminho.

  1. Ao clicar em uma célula na visualização da tabela, os dados da célula são copiados. Ao passar o cursor, aparece um ícone de caneta no lado direito dentro da célula, então a expectativa é que clicar na célula permita editá-la, mas na prática não é isso que acontece. Só ao clicar exatamente no ícone de caneta a célula entra em modo de edição.
  2. O modo de edição da célula é exibido em um modal, e o textarea de entrada aparece grande demais, o que dificulta manter o fluxo de edição. Acho que uma edição inline seria melhor do que um modal.
  3. Não é possível editar os dados por linha.
  4. É um problema bem pequeno, mas o rótulo do botão de alternância do modo escuro muda de acordo com o estado do switch. Quando está desligado, aparece Light Mode; quando está ligado, aparece Dark Mode. Acho que o rótulo de um toggle não deveria mudar.
 
savvykang 2025-01-24

Ao rever a lista de funcionalidades principais, vi que a edição inline está explicitamente mencionada. Fico meio em dúvida sobre o que exatamente é essa edição inline descrita na explicação do projeto.

 
regentag 2025-01-24

Os comandos são dados em linguagem natural por meio de um LLM?
Então não dá para usar em um banco de dados real...

 
leelou2 2025-01-24

Normalmente, ao gerar SQL, usamos a estrutura das tabelas, os relacionamentos e as descrições dos campos, então acho que não deve haver risco de meus dados serem usados para treinamento. Além disso, há a informação de que a OpenAI API não treina com os dados das requisições. Mesmo assim, se você se sentir inseguro, acho que pode usar um LLM local 👏

 
leelou2 2025-01-24

Ah, depois de usar vi que não é um jeito de criar consultas, né? 😂 O uso em um banco de dados real realmente seria bem difícil.

 
regentag 2025-01-24

Parece muito arriscado, por enquanto, fazer tarefas sensíveis em linguagem natural via LLM, especialmente ações como modificar/excluir dados ou alterar a estrutura de tabelas.
No fim, acho que será necessário revisar o SQL gerado antes da execução.

 
vwjdalsgkv 2025-01-24

Acho que esse não é bem o ponto principal do comentário original.
Mesmo em um DB em produção, só um select já pode causar problemas por conta de carga e lock, então a ideia parece ser que há riscos em usar diretamente consultas geradas por um LLM.