MariaDB und HeidiSQL auf macOS nutzen

saerdna

Fleissiger Benutzer
Beiträge
63
Weder MariaDB noch HeidiSQL bieten Versionen für macOS an.

Nutzt jemand von euch beides unter macOS und kann mir Tipps geben, wie ich es zum Laufen bekomme?

HeidiSQL habe ich versucht via Crossover (kommerzielle Variante von WINE) zu installieren. Die Installation läuft zwar durch, ich erhalte aber keine ausführbare Datei um HeidiSQL zu starten.

In der Knowledge Base von MariaDB gibt es ältere Einträge, dass PKGs für macOS existieren sollen. Für aktuelle Versionen von MariaDB werden jedoch keine Installer für macOS angeboten.

Über euren Rat freue ich mich. Danke!

Gruß, Andreas
 
Werbung:
Danke für die Antwort. Da die meisten Webhoster MySQL anbieten, dachte ich, es sei eine gute Idee mit MySQL/MariaDB anzufangen.

Dennoch aus Neugier:
Welche relevanten Vorteile (dabei möchte ich alle Performanceunterschiede außen vor lassen) hat denn PostgreSQL für einen blutigen Datenbanksystem-Anfänger wie mich?

Richtig HeidiSQL wurde mir als exzellenter GUI-Client empfohlen. Gibt es etwas Vergleichbares auch für PostgreSQL?

Und wo wir schon dabei sind:
Empfehlt ihr Python oder PHP, wenn es darum geht ein Webinterface für die Datenbank bereit zu stellen?Existieren für Python ebenso hilfreiche Werzeuge (PHPmyAdmin etc.) wie für PHP.

Kurz: Ich bin in der Orientierungsphase.
 
Unterschiede?

da gibt es schon recht viele, mal einige genannt:

  • freiere Lizenz
  • sehr viel näher am SQL-Standard
  • Window-Funktionen, CTE-Abfragen
  • viel mehr Datentypen, z.B. RANGE, Network Address, UUID, JSON/JSONB, Arrays, Composite Types
  • viel mehr Indexmöglichkeiten, neben normalen BTREE gibt es u.a. GIN, GiST, BRIN. Dazu kommen funktionale und partielle Indexe
  • je Tabelle können in einer Abfrage mehrere Indexe verwendet werden (kann MySQL nicht)
  • ein cleverer kostenbasierter Planner
  • Ausführung einer Abfrage auf mehreren Cores/CPU's
  • viele interne Programmiersprachen (pl/pgsql, pl/perl, pl/python, pl/tcl, pl/v8...)
  • deklarative Partitionierung
  • physical und logical Replication
  • extrem erweiterbar

GUI:

gibt es viele, um einige zu nennen:

  • OmniDB
  • PgAdmin
  • PhpPgAdmin

Ob PHP oder Phyton ist ja eher eine Glaubensfrage, aber mit beiden kannst Du PostgreSQL nutzen, sogar als interne Programmiersprache, um stored procedures und TRIGGER zu programmieren, die im Kern der DB ablaufen.
 
Danke für die Infos.

Wie bewertest Du denn die Unterschiede aus der Perspektive eines Anfängers. Sind sie relevant für ihn?
 
nun, PostgreSQL ist 'sauberer' im Verhalten als MySQL:


MySQL z.B. akzeptiert falsche / inkorrekte Daten wie '0000-00-00' oder '2010-2-31', MySQL akzeptiert zwar die Syntax von Check-Constraints, setzt diese aber nicht durch. MySQL akzeptiert bei Aggregatsabfragen Syntaxfehler und liefert statt einer Fehlermeldung ein falsches Resultat. Anfängerfreundlich geht anders.
 
Ich kann Deine Antworten zum Vergleich der beiden Systeme nicht sinnvoll interpretieren. Sie setzen enormes Fachwissen voraus, was ich nicht habe.

Aber danke trotzdem.
 
Um das an einem Beipiel mal zu zeigen:

Code:
test=*# create table saerdna(spalte_a int, datum date, check (datum > '2018-01-01'));
CREATE TABLE
--
-- folgendes SELECT ist falsch, MySQL würde hier aber keinen Fehler liefern, sondern ein rein zufälliges Ergebniss
--
test=*# select spalte_a, max(datum) from saerdna ;
FEHLER:  Spalte »saerdna.spalte_a« muss in der GROUP-BY-Klausel erscheinen oder in einer Aggregatfunktion verwendet werden
ZEILE 1: select spalte_a, max(datum) from saerdna ;
                ^
--
-- das Datum 31. Februar 2018 gibt es nicht, MySQL würde es aber akzeptieren (zumindest tat es das sehr lange
--
test=*# insert into saerdna (datum) values ('2018-02-31');
FEHLER:  Datum/Zeit-Feldwert ist außerhalb des gültigen Bereichs: »2018-02-31«
ZEILE 1: insert into saerdna (datum) values ('2018-02-31');
                                             ^
--
-- das folgende Datum ist zwar an sich korrekt, verstößt aber gegen den CHECK-Constraint, daß DATUM > 1.1.2018 sein mu0
-- MySQL akzeptiert die Syntax für diesen Check - und auch Werte, die dageben verstoßen
--
test=*# insert into saerdna (datum) values ('2017-01-01');
FEHLER:  neue Zeile für Relation »saerdna« verletzt Check-Constraint »saerdna_datum_check«
DETAIL:  Fehlgeschlagene Zeile enthält (null, 2017-01-01).
test=*#
 
Danke für die Beispiele. Ich habe einen Bekannten, der MariaDB verwendet, um einen Kommentar zu den Beispielen gebeten.

  • 2 Indizes im SELECT: zumindest MariaDB kann das (inzwischen?). Ein Screenshot aus HeidiSQL mit dem EXPLAIN für ein Statement, in dem 2 Indizs benutzt werden:
    upload_2018-8-21_7-20-44.png
    Es wäre ja möglich, dass das in weniger Fällen so verwendet wird als bei PostgreSQL, ich weiß es nicht, aber in der Allgemeinheit ist die Aussage nicht richtig.
  • CHECK wird von MariaDB nach eigener Aussage ab 10.2.1 unterstützt, in MySQL ist das in der Doku für 5.7 beschrieben. Ich habe das mit dem Beispiel von akretschmer getestet, ein Datum in 2017 wird zurückgewiesen.
  • Auch der 31. Februar wird zurückgewiesen.
  • Die Aussage zu "select spalte_a, max(datum) from saerdna ;" ist richtig, MariaDB liefert hier tatsächlich ein verwirrendes Ergebnis und keine Fehlermeldung. Der Maximalwert ist korrekt, aber die Verbindung mit dem Inhalt aus einem einzigen Satz ist nicht sinnvoll. MariaDB beschreibt diesen Fehler übrigens selbst in der Syntaxbeschreibung.
 
Nun, schön zu sehen, daß mit der Zeit die Dinge besser werden.

Zum Explain:

das sind im Grunde genommen 2 Selects, mit UNION verbunden. Ich weiß nicht, ob MySQL bei einer Tabelle mit den Spalten a,b und c und jeweils einem Index darauf innerhalb eines selects, z.B. mit where a=1 and b=2 and c=3, diese 3 Indexe zusammen nutzen kann. Was wohl auch noch immer fehlt, sind weitergehende Indextypen neben BTREE, also z.B. GiST, GIN, BRIN, was noch immer fehlt sind partielle und funktionale Indexe.

Wer MySQL nutzen will, soll es halt machen. Wenn man erst einmal andere Dinge kennt, wird man das aber freiwillig nicht mehr wollen.
 
Wie schon erwähnt, ich bin aufgeschlossen für Empfehlungen und bin in keiner Weise fixiert auf die Benutzung von MariaDB.

Mir fehlt jedoch noch das Verständnis, worin die für mich relevanten Vorteile liegen. Falls Dir noch Beispiele einfallen, die Anfänger wie ich verstehen können, dann poste sie bitte gerne.

Eine ganz andere Frage ist ja, welche hochwertigen GUI-Werkzeuge für das jeweilige DBMS existieren.

Für MariaDB gibt es eine größere Zahl, u.a. eben das hier im Thread erwähnte HeidiSQL.

Graphical and Enhanced Clients

Kannst Du für Postgres ein Werkzeug empfehlen?
 
Wie schon erwähnt, ich bin aufgeschlossen für Empfehlungen und bin in keiner Weise fixiert auf die Benutzung von MariaDB.

Mir fehlt jedoch noch das Verständnis, worin die für mich relevanten Vorteile liegen. Falls Dir noch Beispiele einfallen, die Anfänger wie ich verstehen können, dann poste sie bitte gerne.

Um fair zu sein: mit der Version 8.0 ist MySQL endlich im 21 Jahrhundert angekommen (endlich, endlich gibt es window functions und rekursive Abfragen)

Zwei kompakte Vergleiche findest Du hier:
Aber ein DBMS, das nicht mal ein update foo set a = b, b = a richtig hinkriegt finde ich schon eher fragwürdig.
 
Werbung:
ich nutze keine GUI, daher kann ich auch keine empfehlen. Kollegen von mir sind aber an der Entwicklung von OmniDB beteiligt, und das ist daher auch das, was wir als Firma gern empfehlen.
 
Zurück
Oben