WhoDB - Leichtes und leistungsstarkes Datenbankverwaltungs-Tool

• Ein leichtes, aber leistungsstarkes und benutzerfreundliches Datenbankverwaltungs-Tool mit weniger als 20 MB
  • PostgreSQL, MySQL, SQLite3, MongoDB, Redis, MariaDB, ElasticSearch
• Daten können per natürlicher Sprache abgefragt und verwaltet werden, statt komplexe SQLs zu schreiben: Integration mit Ollama, ChatGPT und Anthropic
• Unterstützung für Tabellenvirtualisierung im Frontend
• Visualisierung von Datenbankschemata als Graph
• Direkte Inline-Bearbeitung von Daten in der Oberfläche und Vorschau der Ergebnisse
• Scratchpad: Datenbank-Abfrageoberfläche im Stil eines Jupyter Notebooks
• In Go entwickelt, daher schnell, und mit Docker einfach zu installieren
• Beziehung zu anderen Tools
  • Entwickelt mit dem Ziel, ein von Adminer inspiriertes Tool zu sein, das auf Leichtgewichtigkeit und Benutzerfreundlichkeit basiert und UX sowie Datenvisualisierung verbessert
  • DBeaver bietet einen großen Funktionsumfang, hat jedoch hohe Ressourcenanforderungen, während WhoDB leichtgewichtig und effizient ist und auch in kleineren Umgebungen gut funktioniert

[bungker]

Der Prompt ist hier definiert: https://github.com/clidey/whodb/blob/main/core/src/common/chat.go Befehle in natürlicher Sprache sind wirklich nur auf einem sehr einfachen Niveau implementiert.
Ich habe es mit ollama und phi4 verbunden, eine einfache DB-Konfiguration erstellt und ein paar Befehle ausgeführt; etwa 10 Befehle wurden korrekt ausgeführt. Ich weiß nicht, wen man dafür loben sollte.

[savvykang]

Ich habe die Demo ausprobiert, und dabei sind mir ziemlich viele Punkte aufgefallen, die verbessert werden könnten. Um sich selbst als leistungsstark zu bezeichnen, scheint das Tool meiner Meinung nach noch einen ziemlich weiten Weg vor sich zu haben.

1. Wenn man in der Tabellenansicht auf eine Zelle klickt, wird der Zellinhalt kopiert. Wenn man mit dem Cursor darüberfährt, erscheint rechts in der Zelle ein Stiftsymbol, sodass man erwartet, dass ein Klick auf die Zelle die Bearbeitung startet – tatsächlich ist das aber nicht der Fall. Nur wenn man exakt auf das Stiftsymbol klickt, wechselt die Zelle in den Bearbeitungsmodus.
2. Der Bearbeitungsmodus für Zellen wird als Modal angezeigt, und das Eingabe-textarea ist übermäßig groß dargestellt, was es erschwert, den Eingabefluss beizubehalten. Ich denke, Inline-Bearbeitung wäre sinnvoller als ein Modal.
3. Daten können nicht auf Zeilenebene bearbeitet werden.
4. Das ist wirklich nur eine Kleinigkeit, aber die Beschriftung des Schalters für den Dark Mode ändert sich je nach Schalterzustand. Im ausgeschalteten Zustand steht dort Light Mode, im eingeschalteten Zustand Dark Mode. Ich finde, die Beschriftung eines Toggle-Switches sollte sich eigentlich nicht ändern.

[savvykang]

Wenn ich mir die Liste der Kernfunktionen noch einmal ansehe, ist dort ausdrücklich Inline-Bearbeitung angegeben. Ich bin mir nicht ganz sicher, was mit der im Projektbeschrieb erwähnten Inline-Bearbeitung gemeint ist.

[regentag]

Bedeutet das, dass man über ein LLM Befehle in natürlicher Sprache gibt?
Für eine echte produktive Datenbank kann man das wohl nicht einsetzen...

[leelou2]

Normalerweise verwendet man beim Erzeugen von SQL die Tabellenstruktur oder Beziehungen sowie Feldbeschreibungen. Daher ist es wohl unwahrscheinlich, dass meine Daten zum Training verwendet werden. Außerdem gibt es die Aussage, dass die OpenAI API nicht mit den Anfragedaten trainiert. Wenn Sie sich trotzdem unwohl fühlen, können Sie wohl ein lokales LLM verwenden 👏

[leelou2]

Oh, nachdem ich es ausprobiert habe, ist das also keine Art, Abfragen zu erstellen 😂 Dann wird der Einsatz in einer echten produktiven DB wirklich schwierig sein.

[regentag]

Sensible Arbeiten, insbesondere das Ändern/Löschen von Daten oder Änderungen an der Tabellenstruktur, per natürlicher Sprache über ein LLM auszuführen, erscheint mir derzeit noch sehr riskant.
Letztlich wird man den vor der Ausführung generierten SQL-Code wohl überprüfen müssen.

[vwjdalsgkv]

Ich glaube, das ist nicht der Kern des ursprünglichen Kommentars.
Selbst in einer produktiven DB können schon SELECT-Abfragen durch Last oder Locks Störungen verursachen; gemeint war wohl, dass es riskant ist, von einem LLM erzeugte Queries direkt zu verwenden.