postgreSQL Client Empfehlung

Ludwigmller

SQL-Guru
Beiträge
171
Als Umsteiger von MySQL (mit phpmyAdmin) würde ich gerne einen Client für postgreSQL empfohlen bekommen.
Wichtig wäre mir automatische Vorschläge beim Schreiben der SQL Befehle. Also z.B. wenn ich "Relation." eingebe möchte ich gerne die Spalten vorgeschlagen bekommen.
Auch wäre es wünschenswert wenn man wie in der MySQL Workbench ein ER-Diagramm der gesamten DB erstellen lassen kann oder auch über das ER Diagramm Tabellen mit Beziehungen erstellen. Beides fehlt beim pgAdmin zum Beispiel.
Ansonsten halt die "normalen", grundlegenden Funktion zur Verwaltung der DB.
 
Werbung:
DBVisualizer ermöglicht das nur in der Pro-Version und DBEaver muss nach 14 Tagen auch eine Lizenz erworben werden, was sich für mein Kleinprojekt nicht lohnt. OmniDB bietet autocomplete und ein Diagramm das Beziehungen veranschaulicht, jedoch fehlen mir da grafische Dialoge zum Einfügen von Datensätzen oder dem Erstellen neuer Tabellen.
Ich überlege ob ich nicht doch bei MySQL und phpmyAdmin bleibe ;) schade, dass es die gleiche Software nicht für postgres gibt
 
Dafür beherrsche ich die Befehle nicht sicher genug. Beispielsweise zum Tabellen erstellen, hilft es mir einen Dialog zu haben wo man die Datentypen auswählen kann. Auch weiß ich häufig nicht mehr wie genau die Spalten der Tabellen heißen, deswegen hätte ich gerne Auto-Complete, welches bei phpmyAdmin einfach perfekt ist.
Aber wahrscheinlich ist das auch alles ein bisschen Gewöhnungssache.
Mein Projekt hat bisher nur ein paar Tabellen (<10). Oder bin ich von phpmyAdmin zu verwöhnt? ;)
 
Beispielsweise zum Tabellen erstellen, hilft es mir einen Dialog zu haben wo man die Datentypen auswählen kann.

Ja, klar, das mag nett sein, und solche Clients gibt es auch. @castorp nannte ja welche. Auf der anderen Seite ist es gut, einmal in der Doku z.B. mal eine Lesetour durch die verfügbaren Datentypen zu machen. Da gibt es richtig coole Dinge, wie z.B. RANGE-Datentypen, oder Network Address - Typen oder UUID oder JSON(B) oder auch Arrays. Man kann sich sogar eigene Tyoen definieren. Dann geht es z.B. mit Constraints weiter: PG 'versteht' nicht nur CHECK-Constraints, es befolgt diese sogar! Oder Indexe: sagen Dir Begriffe wie 'funktionaler Index' oder 'partieller Index' etwas? Oder GIN, GiST, BRIN - Indexe?

Eine GUI kann Dir bei richtig großen Projekten sicherlich viel Arbeit abnehmen, aber die ganzen Features mal an einem kleinen Projekt und 'hardcore' via CLI zu lernen hat auch einen Charme ...
 
Ja die CHECK-Constraints sind ein Grund warum ich gerne wechseln möchte. Bei mir ist das "Problem", das ich nur recht wenig Zeit nebenbei für das Projekt habe und immer mal ein bisschen mache. Dann ist beim nächsten Mal schon wieder einiges vergessen und da wäre etwas mehr Unterstützung in Form einer grafischen Oberfläche natürlich nicht schlecht.
Der standardmäßige pgAdmin war ja noch gar nicht Thema... der bietet nach "Strg+Leertaste" auch auto-complete an. Wahrscheinlich werde ich erstmal damit Vorlieb nehmen.. Notfalls kann man ja auch zwei verschiedene Programme haben und jenachdem was man gerade braucht wechseln. Dann wäre die Konsole auch mit dabei.

Kompliment an akretschmer: du bist ja hier wirklich immer zur Stelle und kämpfst um jeden der postgres nutzt ;)
 
Eine GUI kann Dir bei richtig großen Projekten sicherlich viel Arbeit abnehmen, aber die ganzen Features mal an einem kleinen Projekt und 'hardcore' via CLI zu lernen hat auch einen Charme ...
Viele GUIs sind ja nicht nur "Klicki-Bunti", sondern bieten einen komfortablen Editor zum Schreiben und Ausführen der Befehl und die Darstellung der Resultate ist auch übersichtlicher.

Ob ich jetzt "select * from .." oder "create index ..." in der Kommandozeile, oder in einem Editor eingebe ist für den Lernerfolg nicht wirklich ausschlaggebend.

Gerade am Anfang, wenn man sich oft vertippt oder die falsche Syntax verwendet, ist es wesentlich angenehmer das in einem anständigen Texteditor zu machen als auf der Kommandozeile. Ich verwende auch lieber einen GUI Tool - um SQL einfacher eingeben und ausführen zu können. Das Anzeigen und Analysieren von größeren Resultaten ist mit einer scrollbaren Tabelle schlichtweg komfortabler (ich weiß es gibt pspg um das auf der Kommandozeile auch etwas besser hinzubekommen - aber das ist nicht das Gleiche).

GUI Tools haben auch noch den Vorteil, dass man die Tabellendefinitionen bequem parallel zum Editor anzeigen kann. Oder auch kleine Helfer bieten, wie z.B. das automatische Vervollständigen von JOIN Bedingungen basierend auf FK constraints.

Grundsätzlich komme ich auf der Kommandozeile gut zurecht, aber ich arbeite lieber mit einer "graphischen Kommandozeile"

jedoch fehlen mir da grafische Dialoge zum Einfügen von Datensätzen oder dem Erstellen neuer Tabellen.
Verwende niemals GUI Tools zum Erstellen von Tabellen. Das ist auch bei MySQL keine gute Idee. Wenn Du halbwegs seriös (bzw. professionell) arbeiten willst, sollten alle Befehle zum Erstellen (und Migrieren) Deines Schema mittels Skripte gemacht werden. Idealerweise automatisiert und dann in unter Versionskontrolle gestellt (z.B. git)

Selbst bei einem privaten Kleinprojekt sollte man so arbeiten.

Dass es keine echte Auswahl bei OpenSource Tools für die ER Modellierung gibt, finde ich auch sehr schade. Vor ein paar Jahren sah es so aus, als könnte PowerArchitect eine gute OpenSource Alternative werden - aber die sind leider wieder in der Versenkung verschwunden.

Ich überlege ob ich nicht doch bei MySQL und phpmyAdmin bleibe

Naja, die Entscheidung für (oder gegen) einen Datenbankserver an den Client-Tools festzumachen, ist ein bisschen so wie das technisch schlechtere Auto (höherer Verbrauch, lauter, fehlende Extras) zu fahren nur weil einem die Farbe der Sitze besser gefällt :)
 
Zuletzt bearbeitet:
Gerade am Anfang, wenn man sich oft vertippt oder die falsche Syntax verwendet, ist es wesentlich angenehmer das in einem anständigen Texteditor zu machen als auf der Kommandozeile. Ich verwende auch lieber einen GUI Tool - um SQL einfacher eingeben und ausführen zu können. Das Anzeigen und Analysieren von größeren Resultaten ist mit einer scrollbaren Tabelle schlichtweg komfortabler (ich weiß es gibt pspg um das auf der Kommandozeile auch etwas besser hinzubekommen - aber das ist nicht das Gleiche).

GUI Tools haben auch noch den Vorteil, dass man die Tabellendefinitionen bequem parallel zum Editor anzeigen kann. Oder auch kleine Helfer bieten, wie z.B. das automatische Vervollständigen von JOIN Bedingungen basierend auf FK constraints.
Das sehe ich genauso. Welche GUI Software benutzt du? Gerade die automatische Vervollständigung von JOIN Bedingungen basierend auf Fremdschlüsselbeziehungen klingt interessant.

Verwende niemals GUI Tools zum Erstellen von Tabellen.
Warum nicht?


nun ja, ich lebe auch von PostgreSQL, ist mein täglich Brot ...
Darf man fragen als was du beruflich machst?
 
Zuletzt bearbeitet:
Welche GUI Software benutzt du?
Die oben erwähnte SQL Workbench/J

Verwende niemals GUI Tools zum Erstellen von Tabellen.
Warum nicht?
Weil die Befehle die Du dazu brauchst sowieso als SQL Skripten in der Sourcecodeverwaltung (z.B. git) abgelegt werden müssen. Also musst Du sie irgendwann doch schreiben.

Und nach meiner Erfahrung sind die meisten "GUI Wizards" nur für sehr einfache Tabellen nutzbar. Alles was ein wenig anspruchsvoller ist kriegt man damit nicht gebacken. Und wenn man dann niemals ein CREATE TABLE (oder CREATE INDEX oder ALTER TABLE) selber geschrieben hat, steht man schnell auf verlorenen Posten.

Deinen PHP Code lässt Du ja auch nicht generieren, sondern schreibst ihn selber. Die Skripte um das Datenbankmodell anzulegen (und von Version X nach Version X+1 zu migrieren) sind genauso Code wie PHP. Und dem sollte auch die gleiche Aufmerksamkeit gewidmet werden.

Das ist aber nichts Postgres Spezifisches, sondern gehört einfach zu den Grundlagen einer professionellen Softwareentwicklung. Nur weil man an einem persönlichen Hobbyprojekt arbeitet heißt das ja nicht, dass man da schludern kann.

Wie heißt es so schön: wenn etwas Wert ist getan zu werden, dann ist es auch Wert, gut getan zu werden.
 
hab vor ca. 5 Jahren bei 2ndQuadrant angefangen, diese wurde vor ca. 3 Monaten von EnterpriseDB aufgekauft. Spricht: die zweitgrößte PostgreSQL-Firma weltweit wurde von der Nr. 1 aufgekauft. Hab Consulting, Support & Sales gemacht und verhandle grad mit EDB über meine Zukunft ...
Da können wir uns ja echt glücklich schätzen solch eine Kompetenz hier zu haben . Dann wünsche ich gute Verhandlungen.


Eine andere Funktion die ich aus phpMyAdmin vermisse, ist aus dem Abfrageergebnis direkt ein Diagramm anzeigen zu lassen. Ist teilweise eine echt hilfreiche und schnelle Lösung gewesen.
Auch die Möglichkeit die Reihenfolge der Spalten zu ändern hab ich noch nicht in einem GUI gesehen...
Oder gibt es bei den kostenpflichtigen Programmen einen besseren Funktionsumfang?
 
Auch die Möglichkeit die Reihenfolge der Spalten zu ändern hab ich noch nicht in einem GUI gesehen...
Meinst Du die Reihenfolge der Spalten einer Tabelle?
Das geht in Postgres nicht (genauso wie in praktisch allen anderen Datenbanken außer MySQL).

Und letztendlich ist es auch nicht notwendig: wenn Du die Spalten in einer anderen Reihenfolge haben willst, schreibst Du sie halt in einer anderen Reihenfolge in das SELECT Statement.
 
Werbung:
Auch die Möglichkeit die Reihenfolge der Spalten zu ändern hab ich noch nicht in einem GUI gesehen...
Oder gibt es bei den kostenpflichtigen Programmen einen besseren Funktionsumfang?

siehe @castorp

ergänzend:

"Reihenfolge" ist eine Sache, die man bei Datenbanken nicht erwarten sollte. Erwarte NIE eine immer gleiche Reihenfolge, solange Du kein ORDER BY hast. Konkret, stelle Dir eine Tabelle mit 1 Milliarde Zeilen vor. Wenn Du da ein 'select *' machst, wirst Du die Datensätze in einer bestimmten Reihenfolge bekommen. Erwarte nicht, daß beim nächsten Aufruf diese Reihenfolge gleich sein wird, denn es könnte sein, daß inzwischen ein anderer DB-User dieselbe Abfrage kurz vor Dir abgefeuert hat. Was passiert? Der andere User hat schon 100.000 Rows geliefert bekommen - ein Bruchteil der eigentlichen Menge. PG wird Deine Abfrage mit seiner mergen - Du wirst den 100.001 Datensatz als ersten bekommen - bis zum Schluß - und dann den ersten bis zum 100.000ten.

Warum?

Optimierung!

PG liest die Tabelle ab 100.000 bis zum Ende nur einmal, liefert an beide Clients von da an bis zum Schluß die Rows - und Dir dann vom ersten bis zum 100.000sten die Rows.

Merke: Reihenfolgen in Datenmengen sind nicht existent, solange Du nicht nach einer bestimmten Reihenfolge fragst, also via ORDER BY. Und: select * ist GANZ SCHLECHT in produktivem Code. Stelle Dir eine Personal-Tabelle einer großen Firma vor: zuerst hast Du da Namen und Geburtstag und Einstellungstag. Sagen wir mal, 100 Byte je Mitarbeiter, und du hast 1000 Mitarbeiter. Du hast eine Applikation, die ein 'select *' von dieser Tabelle macht, um eine Liste über Name, Geburtstag, Einstellungstag macht. Easy.

Später fragst Du die Mitarbeiter nach einem Video von - whatever. Jeder Mitarbeiter speichert daher 100GB Video in der Tabelle - für eine bestimmte Anwendung, die dann z.B. nur die Daten FÜR EINEN Mitarbeiter abfragt. Deine alte Anwendung zieht weiter je Mitarbeiter - Du hast 1000 - von nun ab je Mitarbeiter via select * 100GB extra übers Netz - um 1000 mal je 100GB zu ziehen und zu verwerfen - und der DB-Server steht in der Claud ...


Das sind so, vereinfacht, Dinge die man immer wieder sieht ...
 
Zurück
Oben