MySQL - Freies Datenbankverwaltungssystem

MySQL in der aktuellen Stable-Version 5.7.16 ist ein relationales Datenbankverwaltungssystem. Es zählt zu den am weitesten verbreiteten Open-Source-Programmen seiner Art und wird bevorzugt zur Datenspeicherung für Web-Services genutzt, häufig in Verbindung mit dem Webserver Apache und der Skriptsprache PHP.
MySQLMySQL Workbench

Mehrere Speicher-Engines

Der Datenbank-Manager funktioniert nach dem Server-Client-Prinzip: Der MySQL-Server stellt die Daten bereit, welche von Clients abgefragt werden. Dabei kann es sich um mehrere Datenbanken handeln, in denen verschiedene Tabellen angelegt werden können. Jede Datenbank wird mit einer entsprechenden Dateistruktur in einem einzelnen Ordner abgelegt.

Für unterschiedliche Tabellentypen verfügt MySQL über verschiedene Speicher-Engines, wie InnoDB, MyISAM, NDB, Memory, Merge, Archive oder CSV. Mit an Bord sind unter anderem auch verschiedene Arten zur Partitionierung von Tabellen, was der Leistungsverbesserung und besserer Handhabung großer Datenbanken dient.

Alternative Benutzeroberfläche

Die Bedienung von MySQL erfolgt über die mitgelieferte Kommandozeile oder über die grafische Benutzeroberfläche MySQL Workbench. Als alternatives GUI bietet sich das populäre phpMyAdmin an. Die hier zum Download verfügbare MySQL Community Edition ist als quelloffene Version kostenlos, wird allerdings nicht mehr so gut gepflegt wie die kommerziellen Editionen, welche für den professionellen Einsatz gedacht sind.

MySQLMySQLMySQLMySQL

385,19 MB
1.295
Diesen Download empfehlen
Kommentieren17

Das könnte Sie auch interessieren

Jetzt einen Kommentar schreiben
 
Meine Empfehlung lautet klar MariaDB anstatt MySQL :)
 
@Michael96: richtig ! Du hast Recht, vorallen wenn man weis die Eigendlichen Hauptentwickler sind rüber gewechselt zu MariaDB, da sie nicht mehr hinter MySQL stehen wollen. MYSQL iss müll, MariaDB iss Guut :)
 
@Blackcrack:
1. für die kleinen Datenbanken die man so zuhause anlegt reicht MySQL
2. auch bei kleineren Firmen oder Projekten ist MySQL vollkomen ausreichend
3. MySQL und MariaDB sind binär und befehlskompatible, bis auf ein paar kleine Ausnahmen
4. die Experten die sich mit diesen kleinen Ausnahmen auseinandersetzen haben besseres zu tun als hier zu dissen, ihr beide gehört definitiv nicht dazu

die Hauptentwickler sind nicht gewechselt weil MySQL schlecht ist, sondern weil sie mit der Politik von Oracle nicht einverstanden sind, sie wollen also nicht mehr nicht hinter MySQL stehen sondern sie wollen nicht hinter Oracle stehen, eventuell vorher besser belesen bevor man wilde Behauptungen rauswirft

gibt keinen Grund zuhause, in kleineren Firmen oder bei kleineren Projekten auf MariaDB zu wechseln, interessant wird es erst bei Megaprojekten mit riesigen Datenmengen, vorher ist es zweitrangig
 
@Gispelmob: Und dann sollte man vielleicht direkt an etwas in Richtung noSQL denken
 
@Gispelmob: Guter Beitrag. Aber hey: der "Profi" zeichnet sich meist ja dadurch aus, weil er Photoshop installiert, um dann doch nur mit dem Zauberstab freizustellen.
 
@Gispelmob: Schreibt man vernünfties SQL nach Standard läuft das Programm mit allen SQL-Datenbanken, egal ob Mirakle, JosefDB, SQHeavy oder Pregres ;-)
 
@Bautz: Leider nicht ganz; nicht jedes DBMS unterstützt den Standard *vollständig.
 
@RalphS: Mit SQL99 haben wir noch keine Probleme gefunden.
 
@Bautz: Dann hast Du wohl noch kein SQDark verwendet. *lach*

Versteh mich nicht falsch, das ist eine geniale wie einfache Idee mit so einer In-Process-DB. Aber der Entwickler schreibt halt auch selber, daß viele Dinge aus dem Standard noch fehlen, und so Späßchen wie CREATE FUNCTION oder Vergleichbares funktionieren bspw überhaupt nicht (das heißt, geht schon, muß man aber in seiner Anwendung selber programmieren und dann als Extension in den Prozeß laden).

MySQL kann (meines Wissens) auch jetzt noch kein DEFER für Check()s, und JOINs unterstützt kaum ein DBMS *nach Standard*; der eine macht kein RIGHT OUTER und FULL OUTER muß man erstmal suchen. CROSS ja, aber dann eher nach älterem Standard als nach '99. Bin sicher, daß da noch sehr viel mehr dazukommt.

Und wenn es um Dinge geht, die nicht gehen dürften, ist MySQL den anderen weit voraus.
 
@RalphS: Was ich nachwievor vermisse ist das "REPLACE INTO". SQLServer hat mit MERGE INTO zwar war ähnliches, aber längst nicht so einfach und selbsterklärend.
 
@Bautz: REPLACE INTO wo? Im Standard? Da ist was dran, das macht jeder irgendwie anders. Ich persönlich hab ja den Postgres-Ansatz dazu schätzen gelernt (INSERT INTO.. ON CONFLICT DO (NOTHING|<'normales' UPDATE>)), weil man damit ganz gezielt auswählen kann, was passieren soll, wenn der Datensatz schon da ist - PKs kann man schonmal gekonnt aus der Liste rauslassen, aber auch so ganz nach Semantik rangehen: Was ist denn die Situation, wenn der Datensatz schon da ist, den ich grad einfügen wollte? Was heißt das für meine Anwendung? Dann muß ich doch nur X und Y - und komplizierte CASEs fallen weg.

TSQL MERGE kann auch viel, ist aber ebenso wie Oracle MERGE zu umständlich. INSERT (OR) REPLACE/IGNORE ist da netter. Postgres irgendwo dazwischen. Allerdings hält einen auch nix von ab, da eine SP drumherum zu basteln, sodaß man sich das MERGE nie wieder anschauen muß.

Weswegen ich auch davon ausgehe, daß das bis auf Weiteres nicht in den Standard aufgenommen werden wird. Jeder macht halt seinen Müll und keiner wird das aufgeben wollen, weder Entwickler noch Anwender.

MySQL (und Kompatible) können auch SELECT .. LIMIT .. OFFSET, das könnt wegen mir auch gerne in den Standard. Die Standard-Syntax fürs Auswahlfenster ist mir da ein ganzen Ticken zu redundant. :)

Aber am Ende gibt es halt ein paar Dinge, die - soweit es mich betrifft - ein DBMS können *muß* und DEFERed CHECK()s gehören dazu. Wenn ich nicht in der Lage bin, innerhalb(!) einer Transaktion Integritäten verletzen zu können, dann schränkt mich das zu sehr ein, und mh, andere sehen das ganz sicher anders aber ich möcht halt auch ein DBMS haben was mir sagt "hey sorry GROUP BY ohne Aggregat ist albern, da mach ich nicht mit" wenn ich mal nicht aufgepaßt hatte und eben *nicht anfängt, mir *irgendwas zurückzuliefern, wo ich dann also denk 'aha okay geht' was aber ganz offensichtlich *nicht stimmt.
 
@RalphS: Das mit der Integrität finde ich jetzt nicht so kritisch, beim rest: 100% zustimmung.
Ich finde es halt schade, dass man 2016 immer noch eine abstraktionsebene einbauen muss, um unterschiedliche Datenbanken ansprechen zu können. Und es es nur weil jemand die Syntax etwas anders haben will. DB2 z.B. erzwingt bei SUBSTR() Leerzeichen nach den Kommas. Und das nur in dieser Funktion. WARUM?


Kommentar abgeben Netiquette beachten!

WinFuture wird gehostet von Artfiles