- 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
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.
Usei a demo e vi vários pontos que precisam de melhoria. Para se autodefinir como poderoso, ainda parece faltar bastante caminho.
textareade 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.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.
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...
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 👏
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.
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.
Acho que esse não é bem o ponto principal do comentário original.
Mesmo em um DB em produção, só um
selectjá pode causar problemas por conta de carga elock, então a ideia parece ser que há riscos em usar diretamente consultas geradas por um LLM.