- ChartDB ist ein DB-Diagramm-Editor, mit dem sich Datenbankschemata schnell visualisieren und als ER-Diagramme bearbeiten lassen; der Fokus liegt auf Teamzusammenarbeit und Schema-Migrationen
- Die Cloud-Version läuft im Browser und wirbt damit, ohne Datenbankzugriff innerhalb von 15 Sekunden ein Diagramm zu liefern
- Die Self-Hosted-Version wird kostenlos als Open Source angeboten und eignet sich für Anforderungen an Sicherheit und Anpassbarkeit, bei denen Daten und Einstellungen selbst kontrolliert werden müssen
- Unterstützt werden Schema-Import per einzelner Abfrage, KI-generierte ER-Diagramme, Export von SQL DDL, automatische Synchronisierung, Echtzeit-Zusammenarbeit, eingebettete Dokumentation und Änderungsverfolgung
- Nutzbar für das Design verschiedener relationaler DBMS und Cloud Data Warehouses, darunter PostgreSQL, MySQL, SQL Server, SQLite, MariaDB, ClickHouse, CockroachDB, Oracle, Snowflake und BigQuery
DB-Schemadiagramme im Browser bearbeiten
- ChartDB ist ein Tool, das Datenbankschemata sofort visualisiert und ER-Diagramme erstellt
- Es wird als DB-Diagramm-Editor für Teamzusammenarbeit und Schema-Migrationen vorgestellt
- Der Start-Button führt zur ChartDB-App; daneben werden ein kostenloser Einstieg und keine erforderliche Kreditkarte erwähnt
- Auf GitHub wird ChartDB mit +19K stars angezeigt
Optionen: Cloud und Self-Hosted
- ChartDB Cloud visualisiert Datenbanken im Browser
- Wird als geeignet für einfache Nutzung und Teamzugriff beschrieben
- Wird als ohne Datenbankzugriff nutzbar ausgewiesen
- Wirbt damit, innerhalb von 15 Sekunden ein Diagramm zu liefern
- Self-Hosted ist ein kostenloser Open-Source-Editor für Datenbankdesign
- Daten und Einstellungen lassen sich vollständig kontrollieren
- Eine Option für Umgebungen, die Sicherheit und Anpassbarkeit benötigen
- ChartDB erklärt, dass sich eine DB mit einer „einzelnen Abfrage“ visualisieren lässt
Workflow: Import → Edit → Export
-
Instant Import
- Stellt für jede Datenbank eine einzelne Abfrage bereit, mit der das gesamte Schema importiert wird
- Der Schema-Import soll innerhalb von 15 Sekunden möglich sein
-
Relational DBMS
- MySQL, MariaDB, PostgreSQL, Microsoft SQL Server und SQLite werden als beliebte DBMS genannt und als unterstützt ausgewiesen
-
Export SQL
- Diagramme können als SQL-DDL-Skripte heruntergeladen und in der Datenbank ausgeführt werden
- Auch der Export als Bild für Dokumentationen ist möglich
-
Examples
- Vordefinierte Beispiele liefern schnelle Einrichtung und Designreferenzen
- Dieser Punkt ist als WIP markiert
-
Advanced Query Editor
- Bietet Rückgängig, Wiederholen, Kopieren, Einfügen und Duplizieren
- Tabellen, Themenbereiche und Notizen können hinzugefügt werden
-
Beautiful Shares
- Erstellt visuelle Vorschauen von Datenbankdiagrammen, die mit anderen geteilt werden können
Funktionen für Diagrammerstellung, Teilen und Synchronisierung
- ChartDB - AI Agent
- Wandelt in einen Prompt eingegebene Datenbankideen in editierbare, optimierte ER-Diagramme um
- Instant Import
- Importiert das vollständige DB-Schema mit einer einzelnen Abfrage
- Export SQL
- Erzeugt DDL-Skripte im gewünschten SQL-Dialekt
- Sync Database
- Synchronisiert eine Live-Datenbank automatisch mit dem Diagramm
- Real time collaboration
- Teammitglieder können eingeladen werden, um Diagramme in Echtzeit anzusehen und zu bearbeiten
- Amazing Docs
- Erstellt einbettbare Diagramme und anpassbare, erweiterbare Dokumentation
- Keep on track
- Verfolgt Diffs und Versionshistorie von Schema-Änderungen
Unterstützte Datenbanken
- ChartDB gibt an, Design für Datenbanken und Cloud Data Warehouses zu unterstützen
- Als unterstützte Ziele werden folgende genannt
- PostgreSQL
- MySQL
- SQL Server
- SQLite
- MariaDB
- ClickHouse
- CockroachDB
- Oracle
- Snowflake
- BigQuery
Betriebsfragen aus der FAQ
- Es gibt eine Frage dazu, ob ChartDB die Datenbank verändert
- Ein Punkt fragt, ob sich Live-ERDs in Notion, Miro und Confluence einbetten lassen
- Ein weiterer Punkt klärt, ob der ChartDB-Cloud-Plan kostenlos getestet werden kann
- Auch Fragen dazu, wie man Support erhält, Diagramme und Datenbank synchronisiert sowie ob Rechnungen und Business-Zahlungen angeboten werden, sind in der FAQ enthalten
1 Kommentare
Meinungen auf Hacker News
Ich habe schon oft gesehen, dass Projektteams mit der Entwicklung einer neuen Anwendung loslegen, ohne auch nur ein grundlegendes Diagramm zu haben, das irgendeinen Aspekt der Lösung beschreibt, einschließlich des Datenmodells.
Ich weiß nicht, was nötig wäre, damit ein einfaches ER-Diagramm zum Standard in der Projektdokumentation wird. Es gibt viele entsprechende Tools, aber in der Praxis werden sie kaum genutzt.
Vielleicht müsste Microsoft so etwas als Funktion in Excel oder PowerPoint einbauen, damit die Leute es verwenden. Diagramme müssen nicht vollständig sein; sie müssen nur die zentrale Struktur und die Beziehungen im jeweiligen Kontext vermitteln. Bei Bedarf kann man mehrere kleine Diagramme für dieselbe Datenbank erstellen, um Anforderungen und Design zu dokumentieren.
Außerdem war UML beinahe eine Katastrophe. Seit den 90ern hat es sich quasi als repräsentative Diagrammsprache etabliert, hatte aber keine Datenbankkomponenten, sodass man Klassendiagramme irgendwie wie ERDs zurechtbiegen musste. UML ist kein Code, und mit UML zu programmieren ist schwierig oder nahezu unmöglich. Bei ERDs ist es viel einfacher, zwischen Code und Diagramm hin und her zu wechseln; bei anderen Arten des Codierens ist das nicht der Fall.
Ich denke, der Aufstieg und das Scheitern von UML haben wesentlich dazu beigetragen, dass Entwickler keine Diagramme mehr zeichnen. Außerdem reicht den meisten Entwicklern ein Code-Navigationstool, das die Codestruktur als Baum im linken Bereich des Editors anzeigt.
Früher stand ich dem Erstellen von ERDs ziemlich positiv gegenüber und habe es selbst bei Datenbanken mit über 100 Tabellen oft als Onboarding-Aufgabe genutzt. Umfassende ERDs werden jedoch immer seltener, und ich finde das in Ordnung.
Die Wartungskosten sind hoch, daher bleibt der Wert nicht lange erhalten. Ein gut gepflegtes ERD ist schön, aber nicht zwingend notwendig.
Wenn man ERDs aus Code erstellt, werden häufig Tools wie dbdiagram.io oder eraser.io verwendet. ERWin ist so etwas wie der Urvater der UML/ERD-Diagramme, aber teuer.
Ich frage mich, warum Leute solche Tools verwenden. Nutzt man sie, um mit Managern zu sprechen?
Das ist ernst gemeint. Vielleicht sollte ich sie auch nutzen, aber ich weiß noch nicht, warum ich sie brauche.
Sie sind auch nötig, wenn es mehrere Modelle in verschiedenen Systemen gibt, wenn man mit anderen arbeitet und das Datenbankmodell leichter kommunizieren möchte, wenn man es öffentlich erklären muss oder wenn man das Modell im Voraus planen will.
Mit „nutzen“ ist hier das endgültige Diagramm gemeint, nicht unbedingt dieses spezielle Tool.
https://dbml.dbdiagram.io/home/
Wer schon einmal ein Projekt mit 80 Tabellen ohne Dokumentation übernommen hat – oder bestenfalls ein 50-seitiges Dokument mit einem Datenbank-Schema-Dump –, versteht das.
Die wichtigsten Tabellen und Beziehungen lassen sich in einem einzigen ERD (Entity-Relationship-Diagramm) darstellen, und man kann sie in wenigen Minuten verstehen statt in Stunden oder Tagen wie bei einem Schema-Dump.
In der Phase des Schema-Designs kann man verschiedene ERD-Editoren oder textbasierte Diagramm-Tools wie PlantUML, MermaidJS oder DBML verwenden und die Diagrammquellen auch in die Versionsverwaltung legen.
Außerdem kann man in der CI regelmäßig detaillierte ERDs zum aktuellen Datenbankschema generieren und überprüfen, ob es noch zum ursprünglichen Design passt und ob man das aktuelle Schema richtig versteht.
Die Haltung „Der Code ist doch selbsterklärend!“ kann ich wirklich nicht leiden.
Ich sehe viele ähnliche Dienste. Was ich aber suche, ist ein Tool, das ich direkt verwenden oder per Skript steuern kann.
Mein Anwendungsfall ist, aus einer Modellbeschreibung, die Teil eines anderen Prozesses ist, relativ einfache Datenbankdiagramme zu erzeugen. In einer Speicherstruktur habe ich Tabellennamen, Spaltennamen und Beziehungen und möchte ein ER-ähnliches Diagramm zeichnen.
Aktuell schaue ich mir an, aus meinen Daten eine
puml-Datei zu erzeugen und anschließend PlantUML auszuführen, umpngodersvgzu erstellen.Wenn man sucht, findet man meist vollständige Datenbank-Design-Tools mit eigenem Editor, aber ohne API; und Tools wie dieses oder dbdiagram.io sind normalerweise nur online nutzbar, was für mich keine Option ist. Empfehlungen wären sehr willkommen.
Ich wünschte, das hätte es vor fünf Jahren gegeben, als ich ein Projekt gestartet habe. In einem Full-Stack-Projekt mit Postgres musste ich ein Datenbankschema entwerfen und habe mit einer Fachperson aus dem wissenschaftlichen Bereich zusammengearbeitet.
Es war sehr hilfreich, die Diagramme gemeinsam durchzugehen, weil diese Fachperson Probleme erkennen konnte, die sich aus künftigen domänenspezifischen Anforderungen ergeben könnten.
Dabei hatten wir viele Einzelmeetings, und ich habe mir beim Blick auf die Diagramme notiert, was ich bis zum nächsten Treffen ändern musste.
Mit einem solchen Tool hätten wir Änderungen direkt während des Meetings vornehmen und viele Iterationen einsparen können. Es gab zwar auch Dinge wie pgAdmin, aber das wirkte für Nichttechniker nicht besonders zugänglich; dieses Tool könnte die Reibung verringern.
Nett, aber das Hauptproblem solcher Tools ist, dass sie unidirektional sind und sich selbst zur zentralen Autorität machen wollen. Aber das ist ein Bild, keine Datenbank.
Ich verstehe, warum Leute sie nutzen, aber ich brauche solche Tools nicht.
Deshalb bieten alle Tools „Export nach SQL“ an und erwarten zugleich, dass jede Änderung an der Datenbank im Diagramm abgebildet wird. Aber das Diagramm ist nicht die Datenbank – damit hat man plötzlich zwei Dinge zu pflegen.
Ein Diagramm ist ein Modell, und Modelle existieren immer, ob explizit oder nur im Kopf.
Ein Modell im Kopf kann falsch sein, aber niemand kann es sehen und auf Fehler hinweisen – man selbst eingeschlossen.
DBeaver unterstützt ebenfalls ERDs: https://dbeaver.com/docs/dbeaver/ER-Diagrams/
Es ist interaktiv und bearbeitbar. „Schön“ würde ich es nicht nennen, aber das Gesamtprodukt ist FOSS und für Datenbankarbeit enorm nützlich.
Für einige Leute, mit denen ich zusammengearbeitet habe, galt das aber nicht. Typischerweise braucht man so etwas, wenn man beim Design mit Menschen zusammenarbeitet, die zwar nicht mit SQL vertraut sind, aber Domänenwissen haben und mit Excel-Tabellen ankommen, die praktisch schon kleine Datenbanken sind.
Warum ruckelt das Scrollen auf einer statischen Landingpage so stark?