WhoDB - un outil de gestion de bases de données léger et puissant

• Un outil de gestion de bases de données léger, de moins de 20 Mo, mais puissant et convivial
  • PostgreSQL, MySQL, SQLite3, MongoDB, Redis, MariaDB, ElasticSearch
• Permet d’interroger et de gérer les données en langage naturel au lieu d’écrire des requêtes SQL complexes : intégration avec Ollama, ChatGPT et Anthropic
• Prise en charge de la virtualisation des tableaux côté frontend
• Visualisation du schéma de la base de données sous forme de graphe
• Modification directe (inline) des données et aperçu des résultats depuis l’interface
• Scratchpad : une interface de requêtes de base de données dans le style de Jupyter Notebook
• Développé en Go, rapide, et facile à installer avec Docker
• Relation avec d’autres outils
  • Développé avec l’objectif d’un outil inspiré d’Adminer, renforçant l’UX et la visualisation des données tout en conservant la légèreté et la facilité d’utilisation
  • DBeaver offre de nombreuses fonctionnalités mais demande davantage de ressources, tandis que WhoDB est léger, efficace et fonctionne bien même dans de petits environnements

[bungker]

Le prompt est défini ici : https://github.com/clidey/whodb/blob/main/core/src/common/chat.go Les commandes en langage naturel sont en réalité implémentées à un niveau très simple. Je l’ai connecté à ollama phi4, j’ai configuré une petite base de données et j’ai essayé de lui donner des commandes ; une dizaine ont été correctement exécutées. Je ne sais pas vraiment qui il faut féliciter pour ça.

[savvykang]

J’ai essayé la démo, et il y a pas mal de points à améliorer. Il semble qu’il ait encore beaucoup de chemin à parcourir avant de pouvoir se qualifier de puissant.

1. Dans la vue table, cliquer sur une cellule copie ses données. Au survol, une icône en forme de crayon apparaît à droite dans la cellule, ce qui laisse penser qu’un clic sur la cellule permettra de l’éditer, mais ce n’est en réalité pas le cas. Il faut cliquer précisément sur l’icône du crayon pour passer la cellule en mode édition.
2. Le mode d’édition de cellule s’affiche dans une fenêtre modale, et la textarea de saisie apparaît beaucoup trop grande, ce qui rend difficile le maintien du flux de saisie. À mon avis, une édition inline serait préférable à une modale.
3. Il n’est pas possible de modifier les données ligne par ligne.
4. C’est vraiment un détail, mais le libellé de l’interrupteur de bascule du mode sombre change selon l’état du switch. Lorsqu’il est désactivé, il affiche Light Mode, et lorsqu’il est activé, Dark Mode. Il me semble qu’un libellé de toggle ne devrait pas changer.

[savvykang]

En revoyant la liste des fonctionnalités clés, je vois que l’édition inline est bien mentionnée. Mais je ne vois pas très bien ce que signifie cette édition inline indiquée dans la description du projet.

[regentag]

S'agit-il de donner des commandes en langage naturel via un LLM ?
On ne pourra donc pas l'utiliser sur une vraie base de données...

[leelou2]

En général, pour générer du SQL, on utilise la structure des tables, les relations, les descriptions des champs, etc. Donc il est peu probable que mes données soient utilisées pour l'entraînement. Il y a aussi l'information selon laquelle l'API d'OpenAI n'utilise pas les données des requêtes pour l'entraînement. Malgré tout, si cela vous inquiète, vous pouvez sans doute utiliser un LLM local 👏

[leelou2]

Ah, après l’avoir essayé, ce n’est donc pas une approche où l’on construit des requêtes 😂 Son utilisation sur une vraie base de production semble vraiment difficile.

[regentag]

Les opérations sensibles, en particulier celles qui modifient/suppriment des données ou changent la structure des tables, me semblent encore très risquées lorsqu’elles sont effectuées en langage naturel via un LLM.
Au final, il faudra sans doute vérifier le SQL généré avant son exécution.

[vwjdalsgkv]

Je pense que ce n’est pas vraiment l’idée principale du commentaire original.
Même sur une base de données en production, un simple select peut provoquer des incidents à cause de la charge ou de verrous, donc il voulait sans doute dire qu’il y a un risque à utiliser directement les requêtes générées via un LLM.