Diskussion:MySQL

ein abgleich mit der en:-variante wäre gut. --Keichwa 05:43, 22. Nov 2003 (CET)

Aussprache

Das [sprich: mai-es-kju-el] wirkt ziemlich lächerlich und unprofessionell. -- KL47

Technik

Ich finde, dass hier noch etwas tiefgründiger die Funktionsweise beschrieben werde müsste. Das Geschichtliche ist klasse erklährt nur ich mein wenn man über die Administraton sprich, sollte man vielleicht auch erstmal die Funktionsweise klähren. --einstein02

Aus dem Artikel hierher verschoben

Der folgende Abschnitt ist, den ich aus dem Artikel hierher verschoben habe, ist eher ein Tutorial und auch nicht sehr MySQL spezifisch:

MySQL ist auch als Datenbank für Wikipedia im Einsatz, siehe Wikipedia:MediaWiki.

Die Handhabung der Datenbank geschieht entweder manuell über eine Eingabeaufforderung, meist jedoch in Verbindung mit einer anderen Programmiersprache wie PHP, welche die Anfragen an den MySQL-Server stellt und die zurückübermittelten Daten auswertet. Die wichtigesten Befehle zur Steuerung der Datenbank sind die Befehle zum Einfügen (INSERT), Bearbeiten (UPDATE), Lesen (SELECT) und Löschen (DELETE) von Daten in eine Tabelle der Datenbank, wobei Kombinationen dieser Befehle miteinander und mit Bedingungen die Leistungsfähigkeit der Datenbank wesentlich bestimmen.

Die Einrichtung einer Datenbank in MySQL umfasst im Wesentlichen 5 Schritte: 1. die Sammlung und Sichtung der zu verwaltenden Daten 2. die Feststellung über die Relation der Daten zueinander (zB gehört zu einer Postleitzahl immer ein entsprechender Ortsname) und die "Normalisierung" der Daten. Die Normalisierung hat dabei zum Ziel, gleiche Daten nicht mehrmals zu speichern. So würde eine Adressdatenbank nicht EINE Tabelle enthalten, in der die Felder "Name","Strasse","PLZ","Ortsname" enthalten wären, sondern man würde diese Tabelle in 2 Tabellen normalisieren: Tabelle 1 enthielte dann "Name","Strasse","PLZ" und Tabelle 2 enthielte die Felder "PLZ","Ort". Auf diese Weise wird die Information, welcher Ortsname zu einer PLZ gehört nur einmalig gespeichert, wodurch Datenrudundanz (=überflüssig mehrfach gespeicherte Daten) und Fehler vermieden werden. 3. Der Eintrag von Daten in die Datenbank. Um zB die Daten "Beate Bauer","Bauersweg 12","12345","Bauershausen" zu speichern wären die folgenden 2 Befehle notwendig: a) INSERT INTO `tabellenname#1` (Name,Strasse,PLZ) VALUES 'Beate Bauer','Bauersweg 12','12345' b) INSERT INTO `tabellenname#2` (PLZ,Ort) VALUES '12345','Bauershausen' 4. Die Entnahme von Daten aus der Datenbank. Dazu kann man eine Suche über mehrere Tabellen ausführen, was als JOIN bezeichnet wird: SELECT `Name`,`Strasse`,`PLZ`,tabellenname#1.ort,tabellenname#2.plz FROM `tabellenname#1`,`tabellenname#2` WHERE `Name`='Beate Bauer' and tabellenname#1.plz = tabellenname#2.plz; Dieser Befehl weist die Datenbank an, alle Einträge auszugeben, die den befohlenen Kriterien entsprechen: erstens soll das Feld `Name` den Wert 'Beate Bauer' enthalten, zweitens soll aus der Tabelle `tabellenname#2` das Feld `Ort` aus dem Datensatz angehängt werden, der den gleichen Wert für PLZ im Datensatz aufweist. 5. Das Bearbeiten erfolgt mit dem Befehl UPDATE.

Pjacobi 20:40, 27. Jan 2005 (CET)

Literatur

die literaturangaben sollten an die standard-formatierung (siehe Wikipedia:Literatur) angepasst werden - insbesondere sind werbe-weblinks und klappentext-blurbs der verlage unerwünscht. siehe auch Diskussion:Macromedia_Flash#Literatur. grüße, Hoch auf einem Baum 11:51, 5. Mär 2005 (CET)

Es wäre super, wenn man die Bücher etwas ausmistet... Wir sind keine Werbeplattform und sollten daher nur je eins für Anfänger, Fortgeschrittene und Profis anbieten... Einverstanden? Empfehlungen? --Cyper 21:58, 1. Jun 2005 (CEST)

MySQL ist NICHT relational

Auszug: "MySQL ist eine SQL-Datenbank. Wie auch Oracle, DB2 oder PostgreSQL ist MySQL eine relationale Datenbank. [...]"

Weiter steht unter dem Link "relationale Datenbank": "[...] Die Daten werden dabei in Form von zweidimensionalen Tabellen verwaltet, die über Schlüssel (Primärschlüssel, Fremdschlüssel) miteinander verknüpft werden können. [...]"

MySQL kennt keine Fremdschlüssel. Es ist lediglich die Erstellung eines Primärschlüssels möglich. Damit allein lassen sich aber keine Relationen erstellen. Der Nutzer ist bei MySQL völlig allein für die (referenzielle) Integrität seiner Daten verantwortlich. Allein durch die Nutzung externer Tabellenformate, wie InnoDB bzw Berkeley DB wird eine Relationalität ermöglicht. Diese Projekte sind aber getrennt von MySQL zu betrachten.

Falsch

Innodb ist wie MyIsam im Standardumfang einer Mysql-Installation entfalten. Was macht es zum "externen" Tabellenformat? --131.188.24.186 16:03, 18. Apr 2005 (CEST)

Begründung warum NICHT relational

MySQL ist ein Produkt der Firma MySQL AB, InnoDB ein Produkt der Firma Innobase Oy Inc. Zwar ist InnoDB in einer MySQL-Distribution enthalten - was aber nicht heisst, dass es ein Bestandteil ist. Immerhin wird auch Gimp mit Linux ausgeliefert. Ist Gimp daher ein Bestandteil von Linux? Natürlich nicht. Ich bin dafür, dass besser ersichtlich ist, das sich hinter MySQL nur MyISAM verbirgt und alles andere importiert wurde.

Gegenbeispiel: Wäre InnoDB ein Bestandteil von MySQL, dann wären die Entwickler von MySQL AB auch dafür verantwortlich.

Unsinnige Haarspalterei, außerdem falsch

"Immerhin wird auch Gimp mit Linux ausgeliefert."

Du bekommst kein MySQL-Paket ohne InnoDB. Somit ist InnoDB ein Bestandteil von MySQL. Sehr wohl kannst du dagegen Linux ohne Gimp bekommen.

"Ich bin dafür, dass besser ersichtlich ist, das sich hinter MySQL nur MyISAM verbirgt und alles andere importiert wurde."

Es spielt doch keine Rolle wer was entwickelt hat; InnoDB ist ein zentraler Bestandteil von MySQL, MyISAM wird in kaum einer ernstzunehmenden Anwendung eingesetzt.

Foreign Keys

Ein Foreign Key ist ein Constraint, der die Konsistenz der Datenbank garantiert. Es ist voelliger Quatsch, dass er eine Vorrausetzung fuer das relationale Datenbankmodell sei. Die Beziehung zwischen den Tabellen kann auch voellig ohne den Constraint herstellen. Gruss -- sparti 10:46, 14. Jan 2006 (CET)

Schwächen von MySQL

Der Artikel behandelt bisher zu wenig die Schwächen von MySQL, etwa deren mangelhafte SQL-Standard-Konformität. Diese sorgt bei vielen Neulingen aber auch bei MySQL-zu-...-Umsteigern (andersrum sicher auch, aber wer will schon freiwillig von etwas anderem zu MySQL migrieren? ;-)) für viel Verwirrung oder Frust, weil sich MySQL eben nicht an den SQL-Standard hält, sondern vielerorts sein eigenen Süppchen kocht. (Siehe: http://sql-info.de/mysql/gotchas.html )

Dass die Fähigkeiten von MySQL außerdem vom gewählten Tabellentyp abhängen, und man nicht _alle_ Features in einer Tabelle haben kann, ist auch eine – IMHO wwesentliche – Schwäche von MySQL.

--RokerHRO 17:03, 18. Apr 2005 (CEST)

Links

Kann man die Linkliste etwas kürzen? Oder sind alle Links wichtig? Irgendwie kommt es mir doch recht viel vor...--Cyper 22:55, 22. Mai 2005 (CEST)

[X] Done --Qbi 14:39, 23. Mai 2005 (CEST)

>Navicat - Der Zugang zu MySQL ist ein weiteres, kostenpflichtiges GUI Admin-Tool, dass zudem nativ auf den Systemen (Windows, Mac >OS X und Linux) läuft.

---

Was hat das hier zu suchen? Es gibt hunderte MySQL-GUI-Admin-Tools, die auf allen Systemen operieren können...

Hat der SQL dialekt, der von MySQL verwendet wird einen eigen namen?

Literatur: Bücher von Kannengießer

Die Bücher von Matthias Kannengießer wurden vom Autor selbst hinzugefügt: [1],[2] und [3]

Ein anderer Benutzer hielt offenbar nicht so viel von den Büchern: [4]

Da der Autor sein Wikipedia-Konto fast ausschließlich dazu benutzt, seine Bücher in Artikel einzustellen, frage ich mich, ob die hier aufgelisteten Bücher über MySQL tatsächlich den in WP:LIT formulierten Ansprüchen genügen ("Bitte vom Feinsten! Literaturhinweise sollen keine beliebige Auflistung von Büchern sein, die zufällig zum Thema passen, sondern sich auf die zentralen, in der Fachwelt maßgeblichen und richtungsweisenden Werke beschränken.").

Ich persönlich kenne die Bücher nicht, finde es aber nicht in Ordnung, wenn die Wikipedia als Werbeplattform genutzt wird (siehe auch WP:WWNI) und zweifele den neutralen Standpunkt des Autors gegenüber seinen eigenen Büchern an.

Natürlich ist es prinzipiell nicht verboten, als Autor seine Bücher in Artikel zu ergänzen. Die entscheidende Frage ist aber: Entsprechen die Bücher den in WP:LIT formulierten Kriterien auch von einem neutralen Standpunkt aus gesehen oder nicht? Meinungen? --SteBo 14:03, 14. Jul 2006 (CEST)

Wenn man vollkommen neutral gegenüber den Bücher sein möchte, müsste man einen Suchlink mit dem jeweiligen Begriff anzeigen, der dann entweder das Ergebnis von Suchmaschinen oder von Buchhändlern, wie z.B. amazon/lion.cc/buch.de anzeigt, wobei da die Neutralität in Bezug auf den Händler verloren ginge... Die Frage im vorliegenden Fall ist, ob es sich bei Kannengiesser um "zentrale, in der Fachwelt maßgebliche und richtungsweisende Werke" handelt. Beim Einbringen der Links sollte daher u.U. eine Prüfung der eventuell vorhandenen VK-Zahlen und Rezensionen vorausgehen. Da hier der Autor selbst seine Bücher (mehrfach) eingestellt hat, drängt sich aber eher der Eindruck der Verkaufsförderung auf. --217.194.34.103 11:19, 7. Sep 2006 (CEST)

Doppellizensierung

Kann man vielleicht noch was für kommerzielle Nutzer hinzufügen. Ich finde widersprüchliche Aussagen, v.a. aus dem Postgres-Lager, die behaupten, dass die Doppellizensierung alle kommerziellen Nutzer von MySQL zu Lizenzkostenabgaben an MySQL zwingen?! Ist da was dran?

Das gilt für diejenigen kommerziellen Nutzer, die MySQL in eigene Produkte einbinden wollen und diese weitergeben wollen. Wie das mit der GPL nunmal so ist. Da seit Version 4 die Client-Bibliothek ebenfalls unter der GPL steht, betrifft dies also auch Produkte, die nur auf die Datenbank zugreifen wollen. Für kommerzielle Nutzer, die MySQL nur selbst als Datenbankserver einsetzen wollen, stimmt das Argument aber natürlich nicht: Die GPL schränkt die Nutzung der Software nicht ein, nur die Weitergabe. Der Zweck der GPL ist ja gerade, es möglichst schwer zu machen, die Nutzung einzuschränken. Postgres steht unter der BSD-Lizenz und kann also auch ohne weiteres in proprietäre Software eingebunden werden, ohne dass diese damit automatisch quelloffen werden muss. Allerdings sieht sich MySQL nicht im Wettbewerb mit Postgres, da es sich bei beiden Produkten um Open-Source-Projekte handelt und Rivalität zwischen Open-Source-Projekten nicht zielführend sei. MySQL tritt vielmehr gegen die anderen kommerziellen Datenbanksysteme an. Hier sind Lizenzgebühren die Regel, die von MySQL sind deutlich niedriger als die der Konkurrenz. Du siehst also, die GPL betrifft nur diejenigen kommerziellen Nutzer, die sich an Open-Source-Code bereichern und ihn in eigene Produkte einbinden wollen, ohne etwas zurück zu geben. Ob man das "Zurückgeben" nun erzwingen sollte, das ist nur der alte Krieg zwischen Anhängern der GPL und denen der BSD-Lizenz und nichts, was MySQL speziell betrifft. -- daf_? 10:23, 25. Nov. 2006 (CET)

Verständnis

Ich finde, dass der Artikel für Laien noch zu unverständlich ist. Man sollte auch in etwa verstehen, was MySQL kann und wo es angewandt wird, wenn man keine Ahnung von Technik hat. Ich selbst betreibe eine Hp und wollte mich darüber informieren was MySQL eigentlich macht, habe dies aber aus diesem Artikel nicht entnehmen können. (Benutzer:62.104.149.242)

was brauchst du genau an informationen? (ich nehme mal an, dass du mit datenbanken im allgemeinen vertraut bist, oder?) Elvis untot 20:17, 3. Dez. 2006 (CET)

Hallo Elvis untot. Ich bin nicht user 62.104.149.242, habe aber genau das gleiche Verständnisproblem wie er. Ich habe nach der Lektüre des Artikels lediglich verstanden, dass MySQL eine Datenbank ist. Nur ist das keine Hilfe, weil ich immer noch nicht weiß, was man mit MySQL konkret anstellen kann. Gruß, Kurt

Naja, was man mit einer Datenbank - genauer: Mit einem "relationalen Datenbankmanagementsystem" (kurz: RDBMS) - alles anstellen kann, sollte im Artikel Relationale Datenbank eigentlich hinreichend erklärt werden. Kurz gesagt: Man kann daten tabellarisch aufbereitete Daten darin abspeichern, sie anhand verschiedener Kriterien wieder suchen und miteinander verknüpfen, um so zu neuen Daten zu kommen. Z.B. "Gib mir alle Personen, die in den letzten 3 Monaten mehr als 10000 EUR von ihren Konten abgehoben haben oder seit mehr als 6 Monaten ihr Konto überziehen, aber kein Auto über eine Leasingfinanzierung mit unter 36 Monaten Laufzeit gekauft haben." Oder etwas sinnvoller: "Ein TERRORVERDÄCHTIGER ist definiert als Männl. Person zw. 16 und 61 Jahren, gebürtig in einem Staat, der in der Tabelle SCHURKENSTAAT enthalten ist, aufgewachsen in einem solchen staat oder in den USA oder in Frankreich, der einen Pilotenschein in den letzten 3 Jahren gemacht hat, ... usw." - Und dann kann man abfragen: "Gib mir alle TERRORVERDÄCHTIGEN, die in den letzten 2 Tagen ein Flugticket nach Moskau gelöst haben" -> Und die Datenbank spuckts aus, anhand ihrer gespeicherten Daten und der selbstdefinierten Funktion "TERRORVERDÄCHTIGER". :-) --RokerHRO 02:22, 7. Dez. 2006 (CET)

Extreme Stabilität?

Aus dem Text: Die Software wurde sofort unter der Versionsnummer 3.21 veröffentlicht, um zu signalisieren, dass sie auf einem (von Monty entwickelten) Kern basiert, der schon eine sehr lange Geschichte hat. Sie war von Anfang an für große Datenmengen, hohe Verfügbarkeit, extreme Stabilität und sehr gute Performance ausgelegt.

Das mit der Stabilität als auch mit der Verfügbarkeit halte ich für das Gerücht von MySQL Fans, MySQL war in Version 3 nie auf hohe Stabilität ausgerichtet, wie etwa andere Datenbanken. Ganz im Gegenteil, MyISAM ist eher berüchtigt für Stabilitätsprobleme (warum sonst hat MySQL sogar im Sprachkern ein REPAIR TABLE - sowas sucht man sonst üblicherweise vergeblich....). Ich würde vorschlagen zumindest den Passus über Stabilität zu streichen.

Neutralität des Artikels

der Artikel macht auf mich den Eindruck von absoluten MySQL fanboys geschrieben zu sein. Sicher, für 90% aktueller Webanwendungen wird MySQL komplett ausreichnd sein (und auf Grund der fehlenden Funktionalität auch sehr schnell), aber mit "richtigen" Datenbanken wir DB2, Oracle oder PosgreSQL kann es, zumindest was die Fuktionalitäten angeht, auf keinen Fall mithalten. Allein das Fehlen von SUBSELECT oder OLAP disqualifiziert es für bestimmte Anwendungsfälle. (nicht signierter Beitrag von 84.57.153.205 (Diskussion) Conny)

Es hindert dich ja niemand, die Schwächen bzw. Nachteile des Systems zusammenzutragen und im Artikel sachlich und neutral formuliert einzuarbeiten. :-) --RokerHRO 14:57, 13. Jan. 2007 (CET)

subselects werden ab 4.1.* unterstuetzt. und eine unterscheidung zwischne "echter" und "falscher" datenbank machen zu wollen...naja, dafuer ist hier der falsche platz. Elvis untot 19:18, 13. Jan. 2007 (CET)

Darum sollte gerade der Abschnitt "Nachteile/Schwächen" von jemandem geschrieben werden, der sich mit MySQL auskennt. Denn einige der immer wieder zitierten MySQL-Schwächen gehören inzwischen ja der Vergangenheit an. Welche der MySQL Gotchas inzwischen behoben wurden, weiß ich z.B. nicht. --RokerHRO 20:14, 13. Jan. 2007 (CET)

Den Eindruck habe ich auch, gestützt durch Berufserfahrungen mit MySQL Benutzern und Datenbanken. Daten-Inkonsistenzen sind wirklich an der Tagesordnung, abgeschnittene Felder, Datumsangaben die es nicht gibt und ähnliches sind einfach ein Graus. Ich würde ja gerne was zu den Nachteilen und Schwächen schreiben, aber es würde sowieso gleich wieder revertet - so gesehen ist es mir die Mühe nicht wert. --Supersymetrie 10:26, 15. Jan. 2007 (CET)

Zähl doch einfach mal genau auf, was für Probleme du genau mit MySQL hattest (und welche Version das war), was nicht unterstützt wird, was fehlschlägt und wo sich MySQL anders verhält, als andere SQL-Datenbanken bzw. als der SQL-Standard vorschreibt. Wenn das nicht nach stupidem Bashing klingt, sondern relevante und nachprüfbare Fakten enthält, dürfte das kaum revertet werden.

Als Anregung habe ich ja die Liste der MySQL-Gotchas angegeben. Sie bezieht sich aber noch auf MySQL 4.1, bei 5.x soll ja einiges verbessert worden sein. Aber das kann halt nur jemand schreiben, der auch MySQL einsetzt. --RokerHRO 14:20, 15. Jan. 2007 (CET)

nun, da gibt's einige Sachen, die meisten brauchen ein paar Zeilen SQL Code zum Beweis, und dafür ist die Wiki eigentlich nicht da. Aber ein kleines Beispiel was definitv falsch ist und jeder gleich ausprobieren kann (MySQL 5.0.18, Strict Mode): create table foo (bar int) type=innodb; insert into foo values (5); alter table foo add bar1 timestamp; select count(1) from foo where bar is null;select count(1) from foo where bar is not null; Und das ist definitiv falsch, ganz davon abgesehen dass 0000-00-00 00:00:00 sowieso kein gültiger timestamp ist. --Supersymetrie 16:44, 15. Jan. 2007 (CET) (hab grad noch einen cut-and-paste fehler behoben) --Supersymetrie 16:48, 15. Jan. 2007 (CET)

Aha. Das klingt, als ob für MySQL 5.x immernoch Bedarf für so eine Gotcha-Webseie besteht, da auch aktuelle MySQL-Versionen noch "überraschendes Verhalten" zeigen. Vielleicht sollte man so etwas mal aufsetzen, incl. nachprüfbarer Beispiele und vom Artikel hier dann darauf verweisen. Dann kann ja von den MySQL-Fans niemand sagen, die Kritik sei haltlos und unbegründet, oder? --RokerHRO 16:53, 15. Jan. 2007 (CET)

Noch ein Beispiel (MySQL 5.0.18, Strict Mode): create table foo (bar timestamp) type=innodb; insert into foo values (NULL); select count(1) from foo where bar is null; Den Fehler würde ich mal in die Kategorie schwerer Fehler einordnen, Behandlung von NULL ist hier eindeutig fehlerhaft. Weiters ebenso im Strict mode: create table c (id int not null check (id < 1000)) type=innodb; insert into c values (1000); --Supersymetrie 17:19, 15. Jan. 2007 (CET)

Also, denke auch, dass der Artikel etwas unkritisch mit MySQL umgeht. Auf der anderen Seite, sind einzelne Bugs nicht relevant. Objektiv fehlen MySQL aber Dinge wie Subtransactions, wie hoch ist die Abdeckung von SQL98 (zB. Objekt Relationale Erweiterungen). Wie sieht es mit der Skalierbarkeit unter hoher Last aus. Und gibt es Statistiken ueber die Verfuegbarkeit von MySQL? Solche Dinge sind interessant und machen den Unterschied zwischen einer Enterprise Datenbank. -- sparti 17:53, 15. Jan. 2007 (CET)

Einzelne Bugs lassen sich sicher verschmerzen. Aber eine systematische Falschbehandlung von Constraints und Nullwerten disqualifiziert eine Software eindeutig davon, "relationales Datenbanksystem" genannt zu werden. Falls dem bei MySQL so ist, gehört so etwas auf jeden Fall in den Artikel. --RokerHRO 09:28, 16. Jan. 2007 (CET)

In wie fern findet eine systematische Fehlbehandlung statt? Ist das irgendwo dokumentiert? Ich denke wir sollten nur Dinge in den Text schreiben, die unabhaengig von individuellen Systemen nachvollziehbar sind. -- sparti 09:48, 16. Jan. 2007 (CET)

Siehe oben, Beispiele des SQL Codes sind ja in der Diskussion. --Supersymetrie 10:23, 16. Jan. 2007 (CET)

Einzug zurückgesetzt

Naja, die Gotchas, die auf der von mir oben genannten Seite waren ja keine (versehentlichen) MySQL-Bugs, sondern das Verhalten war in der MySQL-Doku so dokumentiert worden. Nur rechnet man als Anwender eigentlich nicht damit, dass bestimmte Constraints (z.B. NOT NULL oder id<1000) einfach ignoriert werden, wenn man bestimmte Tabellenoperationen macht. Dass etwa beim INSERT eines unvollständigen Datensatzes die fehlenden Elemente als NULL eingefügt werden, obwohl doch eine NOT NULL-Constraint gesetzt war.

Ich finde es irgendwie schon sehr befremdlich, wenn man einen Bug (im Sinne von "nicht SQL-standardkonformes Verhalten") dadurch "fixt", in dem man in der Programmdoku schreibt, dass das Programm etwas anderes macht, als vom Standard gefordert und vom Anwender erwartet.

Ich habe hier leider kein MySQL installiert, um zu testen, welche der "Gotchas" bei aktuellen MySQL-Versionen noch auftreten und welche inzwischen behoben worden sind. --RokerHRO 10:08, 16. Jan. 2007 (CET)

Korrekturen Geschichtliches

Ich habe den Hinweis auf "hohe Verfügbarkeit" und "extreme Stabilität" überarbeitet. Bitte bei Hochverfügbarkeit nachlesen, dann sollte klar sein warum MySQL dafür nicht qualifiziert war/ist. Bezüglich Stabilität ist zu sagen, dass dies sicher anfangs kein Designkriterium war (warum gibt es sonst ein REPAIR TABLE Kommando, sowas sollte bei einer stabilen DB eigentlich nicht erforderlich sein. Ganz klar, in beiden Bereichen hat sich seither was getan, nur war MySQL dafür von Anfang aus nicht ausgerichtet. --Supersymetrie 09:53, 16. Jan. 2007 (CET)