Diskussion:MySQL/Archiv

Abgleich mit der englischen Variante

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

Danke für den Hinweis. Den Abgleich habe ich gemacht. Der deutsche Artikel ist inzwischen ausführlicher, als der englische. --Julius-m 22:17, 14. Jun. 2007 (CEST)

XAMPP

... der beteiligten Software als LAMP bzw. WAMP (mittlerweile als XAMPP) bezeichnet ...

also WAMP wird mittlerweile als XAMPP bezeichnet ?!? hab ich das richtig verstanden? denn das wär imho _falsch_ xampp ist sowohl fuer linux als auch fuer windows (und andere verfügbar) ... --Eaglo

Da hast du recht, das XAMPP ist ein Projekt welches ein solches Paket fuer mehrere Betriebssysteme schnuert (wobei das X mit W, L, M, B, usw. ausgetauscht werden kann). --84.57.98.116 19:50, 20. Sep. 2007 (CEST)

Zu XAMP gibt es einen eigenen Wikipedia-Artikel. --Julius-m 09:26, 24. Jan. 2008 (CET)

Aussprache

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

ist außerdem nicht ganz richtig. Im MySQL Reference-Manual 5.1 steht in Kapitel 1.4: Die offizielle Aussprache von „MySQL“ ist „Mai Es Ku Ell“ (nicht „Mai Sie Quell“). -- 82.135.37.138 14:55, 20. Mär. 2007 (CET)

Ja, das hat er doch geschrieben.... --01:43, 19. Sep. 2008 (CEST)

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)

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)

Eine Liste der Abweichungen vom SQL-Standard fände ich eine sinnvolle Ergänzung in diesem Artikel. Die Liste muss ja nicht gleich vollständig sein, sondern kann ja von verschiedenen Autoren ergänzt werden. Im Übrigen sollten diese Abweichungen in der aktuellen Version wesentlich weniger geworden sein im Vergleich zu früheren Versionen. -- 82.135.37.138 15:02, 20. Mär. 2007 (CET)

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?

Nein hat er nicht. Es ist dasselbe SQL, dass auch von DB2 und Oracle unterstützt wird. Keine DB unterstützt den SQL3-Standard 100% So eben auch MySQL nicht. -- 82.135.37.138 10:54, 19. Mär. 2007 (CET)

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)

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)

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) )

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 (1)

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)

Ja, die Gotchas sind leider nicht mehr aktuell. Aber im Prinzip das, was wir brauchen.

Leider ist die Vorgehensweise von MySQL eher typisch. Selbst die echten Enterprise Datenbanken erfullen die Standards nicht 100%. Das zu erreichen waere mit Kosten verbunden, die nicht zu rechtfertigen waeren. Mal ueberspitzt: Wenn 10 Prozent der Features/Bugfixes 90% der Zeit kosten, dann ueberlegt man, ob es nicht auch ohne die 10% geht. Am Beispiel MySQL scheint es sehr gut ohne die 10% zu gehen.

Naja, man muss sich halt ueberlegen, wieviel man fuer die Sicherheit seiner Daten ausgeben moechte. Unsere Aufgabe hier sollte es sein, darueber objektiv aufzuklaeren. -- sparti 11:59, 16. Jan. 2007 (CET)

Naja, es geht nicht um 100% SQL-Konformität. Aber Datenkonsistenz halte ich für das wichtigste, was ein RDBS sicherstellen muss. Sonst ist es keins. Und bei fehlerhaften Eingaben stillschweigend fehlerhafte Datensätze (in dem Sinne, dass sie Constraints verletzen) in die DB einfügen, anstatt die Eingabe zurückzuweisen, ist IMHO inakzeptabel. Alle anderen bekannten RDBS machen eine entsprchende Überprüfung ja schließlich auch, auch kostenlose Systeme. --RokerHRO 16:12, 16. Jan. 2007 (CET)

Ja, ich versteh Dich schon. Aber moechtest Du das im Artikel zum Ausdruck bringen und wenn dann stellt sich die Frage wie? Ich denke, dass ein objektiver Vergleich zu kommerziellen Datenbanken interessant waere. Und das in Punkto Features sowie Anzahl kritischer Bugs und Performance. Gibt es da was? -- sparti 20:36, 16. Jan. 2007 (CET)

Ich hätte so etwas schon gerne im Artikel. Ich finde, damit ein Artikel über eine Software den NPOV behält, muss er die Stärken und Schwächen der Software erwähnen. Doch so ein Abschnitt muss ja so sachlich und mit stichhaltigen Quellen belegbar sein, wie es nur geht. Dafür reichen zum einen meine MySQL-Kenntnisse nicht aus, zum anderen wäre ich viel zu voreingenommen, um so etwas zu schreiben. :-) --RokerHRO 07:57, 17. Jan. 2007 (CET)

Ich finde, das gehört bei allen Datenbanken gemacht. Ich habe sehr gute Erfahrungen mit PostgreSQL, dort bereite ich das schon vor, für MySQL wäre es sinnvoller wenn es jemand mit sehr guten MySQL Erfahrungen macht - wie Du schon gesagt hast. --Supersymetrie 10:29, 17. Jan. 2007 (CET)

Ich habe einfach mal einen Anfang gemacht und eine Liste der Fehler und fehlenden Funktionen begonnen. Als Beweis für Fehler in der Null-Verarbeitung habe ich die beiden Beispiele von Supersymetrie als unsichtbare Anmerkung eingefügt. Ich bitte darum, dass diese Liste fortgesetzt wird oder dass hier Vorschläge gemacht werden, wie man das sonst in den Artikel aufnehmen könnte. -- 82.135.37.138 12:58, 16. Mär. 2007 (CET)

Sorry, aber es interessiert niemand einzelne Bugs. Und was Du glaubst, was User denken, ist wohlkaum ein objektives Qualtiaetskriterium. Das war ein sehr gutes Beispiel dafuer, wie man es nicht machen sollte. -- sparti 13:05, 16. Mär. 2007 (CET)

Das ging aber schnell. Es sind noch keine 10 Minuten vergangen, da ist meine Textänderung schon wieder weg! Mach doch selber mal einen konkreten Vorschlag, wie man diese (offensichtlich wichtigen) Sachen in den Artikel aufnehmen oder beschreiben sollte. Hier auf der Diskussionsseite ewig lang rumlamentieren und einen Beitrag von einem anderen einfach nur löschen, bringt den Artikel nicht weiter. Ich hab' dich jetzt mal etwas salopp angesprochen, aber im Ernst: ich finde eine Liste der SQL3-Funktionen, die im MySQL nicht unterstützt werden, sehr wohl sinnvoll, solange man sich auf die Wesentlichen Unterschiede beschränkt. Grüße -- 82.135.37.138 13:43, 16. Mär. 2007 (CET)

Ich schlage vor, dass wir den Link zu der MySQL Gotchas-Seite unter den Weblinks aufnehmen. (Dieses Mal will ich etwas vorsichtiger sein und hier erst mal einen Vorschlag machen, damit dann hoffentlich eine Artikeländerung entsteht, die eine Haldbarkeit von etwas mehr als nur 10 Minuten hat. Inzwischen habe ich mir einen Nichmamen zugelegt) (JM) --Julius-m 12:01, 31. Mär. 2007 (CEST)

Hallo Julius, freut mich, dass Du dir einen Account zugelegt hast. Das macht die Zuordnung in Diskussionen schon etwas einfacher.

Wie bereits gesagt ist die Gotchas Liste nicht mehr aktuell. Es hat wenig Wert einer Datenbank bereits behobene Probleme vorzuwerfen. Eine Seite mit aktuellen Maengeln waere aber sicherlich hilfreich. -- sparti 17:53, 31. Mär. 2007 (CEST)

Zwei Anmerkungen habe ich dazu: 1. Es gibt bestimmt auch noch Anwender, die die Version 4.x nutzen. Für solche Leute kann eine Info über die in dieser Version enthaltenen Fehler sinnvoll sein. Deswegen könnte - aus meiner Sicht - ein Link zur Gotchas-Seite durchaus in die Weblinks aufgenommen werden. 2. Ich experimentiere in der letzten Zeit ziemlich viel mit MySQL herum. Ich könnte mir vorstellen, einige der in der Gotchas-Liste gemeldeten Fehler einfach mal mit der Version 5.0 auszuprobieren. Diese Ergebnisse - wenn ich dabei Fehler finde, die in 5.0 noch da sind - würde ich gerne in geeigneter Form im Wikipedia festhalten. In welcher Form könnte man das machen? Was wäre Dein Vorschlag? Vielleicht auf einer eigenen Seite --Julius-m 19:36, 31. Mär. 2007 (CEST)

Also das Problem ist doch, dass einzelne Mängel nicht enzyklopädische relevant sind, da sie jederzeit und ohne Mitteilung durch einen Patch behoben werden können. Außerdem ist eine solche Liste eine permanente Quelle für Streit. Wer will festlegen, was wichtig genug ist, dass es dort aufgeführt wird bzw auch von keiner anderen Datenbank unterstützt wird? Ich würde daher vorschlagen, eine solche Seite extern zu pflegen und hier als Quelle für eine Zusammenfassung aufzuführen. -- sparti 23:01, 31. Mär. 2007 (CEST)

Einzug zurueckgesetzt (2)

Nun habe ich einen 2. Versuch gestartet, um "Fehler" zu beschreiben. Ich habe einen Abschnitt Mysql#Einschränkungen hinzugefügt. Ich bitte um Feedback, ob das in dieser Form ok wäre. --Julius-m 08:54, 5. Apr. 2007 (CEST)

Ok, damit kann ich schon leben. Allerdings haben alle Datenbanken solche Animositäten, es bleibt die Frage wie detailliert man sowas beschreiben soll und warum es bei anderen Datenbanken nicht gemacht wird. -- sparti 09:18, 5. Apr. 2007 (CEST)

Es steht Dir ja frei dass auch bei anderen Datenbanken zu machen, solange es fundiert ist. Ich denke aber auch, dass der Abschnitt hier kurz gehalten werden sollte, plus evtl. ein Link auf die MySQL Gotcha Liste. Würde sich übrigens auch bei Postgres anbieten (auch dafür gibt's ja eine Gotcha Liste), darum werde ich mich kümmern. Trotzdem sollten solche Sachen nicht unter den Tisch gekehrt werden. Weiters würde ich es für sinnvoll halten, sich beim Artikel auf erschienene Versionen zu beschränken (also 5.0.x), im Beitrag ist teils schon von 5.1/5.2 (also ungelegten Eiern) die Rede. Solche Punkte wie zukünftige Entwicklungen sollten eher in einem neuen Punkt "Roadmap" (wording???) zusammengefasst werden. --Supersymetrie 10:40, 5. Apr. 2007 (CEST)

Also, ich weiß nicht, warum ich mir die Mühe machen sollte, etwas in die Wikipedia zu schreiben, von dem ich glaube, dass es dort nicht hingehört? Ich kann nur auf die Inkonsistenz hinweisen, die sich daraus ergeben.

Und Du hast bereits ein Problem angesprochen, vor dem ich gewarnt habe. Über welche Version und welchen Patchlevel reden wir denn? Wer pflegt das ganze? Wikipedia hat nicht die Aufgabe, Produkte zu testen und hier die Ergebnisse zu veröffentlichen. Auch vergleichen wir nicht. Eine Enzyklopädie weist lediglich darauf hin, dass es Testberichte und Vergleiche gibt. Aber die dürfen strenggenommen nichtmal von einem Wikipedia Autor stammen, da sich sofort der Verdacht der Befangenheit aufdrängt. -- sparti 11:02, 5. Apr. 2007 (CEST)

Da stimme ich Dir zu, die Wartung wird dann definitiv einein Problem werden. Dann aber Frage ich mich ob der Sinnhaftigkeit der Einträge "aktuelle Version", sowie der detaillierten Aufzählung von (teils sinnlosen) Speicherengines, deren Featureset sich ja auch laufend ändert. Ich dachte eigentlich, Sinn der Wikipedia Einträge ist eine neutrale Sicht, und das sehe ich hier einfach nicht als gegeben an, wenn hier begeistert von 6 Minuten Downtime pro Jahr gesprochen wird (was ich stark bezweifle), im Gegenzug aber nicht erwähnt werden darf dass MySQL teils schwerwiegende Defizite hat. Mangels Perspektive halte ich mich daher ab sofort aus der ganzen Diskussion und dem Artikel raus, es hat keinen Sinn hier so. --Supersymetrie 11:21, 5. Apr. 2007 (CEST)

Nun in diesem Punkt sind wir uns vollkommen einig. Ich habe keinen Probleme damit unbewiesene Behauptungen sowie inhaltslose Listen zu entfernen. Irgendwie hatte ich nur den Eindruck, dass das nicht erwünscht sei. -- sparti 14:00, 5. Apr. 2007 (CEST)

Die Pflege solcher Beiträge ist - aus meiner Sicht - überhaupt kein Problem. Solange sich genügend viele Leute finden, die die Infos über die aktuelle Version zusammentragen geht das alles. Sollte einmal die Situation entstehen, dass schon längst eine neue Version verfügbar ist (z.B. die Version 6.0) und in dem Artikel nur ewig lang die neuen Features und die Schwächen der Version 5.0 und die Ankündigungen für 5.1 bis 5.9 beschrieben sind, dann kann man diese alten Sachen einfach löschen. Dann verkleinert sich ein solcher Artikel eben wieder. Wenn bestimmte Speicher-Engines in zukünftigen Versionen nicht mehr unterstützt werden, dann weg damit. Im Januar 2007 hatte der Artikel die Länge von ca. einer Seite. Weil ich mich gerade mit MySQL intensiv beschäftige, macht es mir Spaß, meine gewonnenen Ergenntnisse hier festzuhalten. Wenn ich bei Erscheinen der nächsten Version kein Interesse mehr daran habe, und sich niemand anderes findet, der das weiter machen will, dann hätte ich auch kein Problem damit, wenn jemand den ganzern Artikel wieder auf die ursprüngliche Länge reduzieren würde. Trotzdem finde ich, dass der Artikel für die aktuelle Version sehr informativ geworden ist und genau dem Anspruch eines Lexikons entspricht. Kurz und knapp werden die aktuellen wesentlichen architektonischen Eckpunkte beschrieben - im Vergleich zum Zustand des Artikels zum Jahresanfang 2007, wo mit blumigen Worten überschwenglich die unglaublichen Vorzüge dieser Datenbank angepriesen wurden...

Wenn Du (Supersymetrie) meinst, dass bestimmte Abschnitte hier nicht hin gehören z.B. die Speicher-Engines, dann lass uns darüber diskutieren.

Ich möchte auch auf die englische Version von MySQL hinweisen. Mir gefällt die Art und der Umfang, wie diese kritischen Themen dort beschrieben sind. Den Punkt 4.3 Future Releases würde ich gerne in den deutschen Artikel aufnehmen. Gerade MySQL hat sich in der letzten Zeit sehr stark verändert und hat sehr große Pläne für die Zukunft. Daher haben die Ankündigungen zukünftiger Funktionen hier eine größere Bedeutung, als für die meisten etablierten DBMS. Als Überschrift sollte aber eine deutsches Bezeichnung gewählt werden. 'Roadmap' gefällt mir nicht so gut. Wie wäre es mit der Überschrift: == Ankündigungen für zukünftige Release == ? --Julius-m 16:15, 6. Apr. 2007 (CEST)

Also meiner Ansicht nach ist alles, was zu dem Thema zu sagen gibt gesagt. Vielleicht nur noch ein Hinweis darauf, dass im englischen Artikel zum Thema Kritk eine Neuralitaetswarnung steht. Gruss -- sparti 10:16, 7. Apr. 2007 (CEST)

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)

Eine Verfügbarkeit von 99,999% ist sogar noch mehr als Hochverfügbar. -- 82.135.37.138 13:17, 13. Mär. 2007 (CET)

Du hast offensichtlich nicht verstanden was Hochverfügbarkeit heisst. Ich kann ein Windows 98 System auch ein Jahr lang laufen lassen ohne dass es etwas tut, und damit ist es noch lange nicht auf Hochverfügbarkeit ausgelegt ist. --Supersymetrie 12:21, 23. Mär. 2007 (CET)

(Mein Klugscheisser-kommentar dazu:) Nein, kannst du nicht. Win 98 hat einen schönen Bug, der das System auch im absoluten Leerlauf nach einer ganz best. Zeit, (weiss nicht mehr genau, Größenordnung ~ 100 Tage) zuverlässig abstürzen lässt :-) --62.214.235.116 09:58, 1. Dez. 2008 (CET)

Doch hat er schon. Er sagt nur, dass Hochverfügbarkeit bereits bei 99,99% erreicht ist. Aber ok, das grenzt schon ans klugscheissen :) -- sparti 14:29, 23. Mär. 2007 (CET)

Ich weiß genau, was Verfügbarkeit bedeutet. Außerdem sind in Hochverfügbarkeit die einzelnen Abstufungen ja genau beschrieben. Ich halte diese Zahl für eine MySQL-DB selber für sehr hoch gegriffen, deswegen habe ich in den Artikel ja extra reingeschrieben: "Nach eigenen Angaben". Ich stelle mir das so vor, dass bei dieser Messung ein Cluster mit z.B. 100 Rechnern verwendet wurde, die alle die selben Daten gespeichert haben und Zugriffe aus dem Web entgegebnehmen und ausführen. Wenn dann jeden Tag mal ein par Rechner kaputt gehen und ausgetauscht werden müssen oder eine Datenbank runter und wieder hochgefahren werden muss, dann fällt das gesamte Cluster nicht aus. Auf diese Weise kann man schon einen permanentn Betrieb sicherstellen und eine Ausfallzeit (d.h. dass das System überhaupt nicht die Anfragen aus dem Web beantworten kann) von wenigen Minuten im Jahr erreichen. (JM) -- 82.135.37.138 17:22, 23. Mär. 2007 (CET)

Hast Du auch Quellen, dass Clustering ein Designkriterium für MySQL waren? Wir sprechen immerhin hier von der geschichtlichen Entwicklung von MySQL, nicht von Entwicklungen der letzten Zeit. Bez. obigen Beispiels, dies ist ein ausschliessliches Lese-Szenario und dadurch nicht gerade realistisch, auch im Web nicht. Wieviele grosse Anwendungen im Web gibt es, die keine Schreiboperationen haben? Und wenn es Schreiboperationen gibt, dann muss es bei MySQL einen Master geben (Multimaster gibt es noch nicht, vom MySQL Cluster mit Nur-Hauptspeicherbetrieb mal abgesehen) , der wiederum dann die Verfügbarkeit vorgibt. Ganz so einfach wie oben beschrieben ist das nicht.... --Supersymetrie 13:49, 27. Mär. 2007 (CEST)

Das stimmt. Die Hochverfügbarkeit war kein Designkriterium für MySQL. Folglich ist es wohl korrekt, dass dieser Satz aus dem Abschnitt Geschichte entfernt wurde. Diese Zahl 99,999% habe ich ja in den Abschnitt Cluster-Technik reingeschrieben. Die Quelle steht dabei. Diese Zahl betrifft wohl die aktuelle Version. (JM)

Die Frage ist natürlich, ob bei diesem Test nur Lesezugriffe vorkamen, oder auch Datenaktualisierungen, Backup, Recovery von verloren gegangenen Änderungen, Reorganisationen, Einspielen neuer Release. Denn genau das sind ja üblicherweise die Ursachen für Downtimes von Informationssystemen. Darüber gibt die Quelle leider keine Auskunft. Meine persönliche Vermutung ist, dass das alles nicht mitgetestet wurde, aber ich kann es nicht beweisen. Sollte ich mit meiner Vermutung richtig liegen, dann ist das nichts Besonderes. Eine solche Leistung würde auch jede andere Datenbank abliefern. (JM) -- 77.176.222.233 14:15, 25. Mär. 2007 (CEST)

Eine Verfügbarkeit von 99,999% wird - und das halte ich für wesentlich glaubwürdiger - zum Beispiel von der IBM für das System OS390 angegeben. Das aktuelle System z/OS soll noch besser sein. Das zeigt jedenfalls, in welcher Liga man spielen muss, um solche Vergügbarkeits-Leistungen zu erreichen. (JM) -- 77.176.222.233 21:40, 25. Mär. 2007 (CEST)

Typischer weise werden nur die Service Hours fuer die Verfuegbarkeit gewertet, also die Zeit in der ein System laut vertraglich geregeltem SLA laufen muss. Changes sollten also nur ausserhalb der Service Hours ausgefuehrt werden, da sie dann nicht die Verfuegbarkeit belasten. -- sparti 18:45, 25. Mär. 2007 (CEST)

Hochverfügbarkeit ist etwas mehr als Zuverlässigkeit im Normalbetrieb. Alleine schon die Tatsache, dass MySQL mit Standardeinstellungen MyISAM Tabellen verwendet (oder auch bei InnoDB Einstellungen, die nicht schreibsicher sind Quelle http://drbrain.livejournal.com/61705.html), dann brauchen wir überhaupt nicht von Hochverfügbarkeit reden. Ein Stromausfall oder Ausfall Netzwerk zum SAN führt je nach Schreibszenario zu umfassenden Reparaturmassnahmen (REPAIR TABLE bsp), dass eine Hochverfügbarkeit (99,99%, 52 Minuten / Jahr - da dauert u.u. das Repair Table deutlich länger) einfach nicht garantiert werden kann. Ich finde es jedesmal auf neue faszinierend, dass Leute Verfügbarkeit im Normalbetrieb mit Hochverfügbarkeit verwechseln. Dass eine Datenbank während des Normalbetriebes zu 99.999% das tut was sie tun soll ist, ist ja wohl keine Leistung, sondern hoffentlich eine Selbstverständlichkeit. --Supersymetrie 13:34, 27. Mär. 2007 (CEST)

Ich bin nicht sicher, ob ich dich richtig verstanden habe. Aber unter Verfügbarkeit steht ja auch schon alles. Bei einem SLA wird die Verfügbarkeit innerhalb eines festgelegten Zeitraumes verlangt. Das heißt der Kunde legt mit dem Service Anbieter fest, in welchen Zeitraum das System laufen muss. Nur wenn innerhalb dieser Zeitspanne ein ausserplanmäßiger Ausfall stattfindet, geht dies zu Lasten der Verfügbarkeit. Alles andere ist der persönliche Ehrgeiz des Admins. -- sparti 14:36, 27. Mär. 2007 (CEST)

Ich kann Deinem Einwand (Supersymetrie) nur zustimmen, dass es sehr zweifelhaft ist, was MySQL da auf seiner Webseite für Zahlen veröffentlicht. Wenn es wirklich nur ein System zum Lesen war, dann ist das echt keine besondere Leistung. Trotzdem finde ich es ok, in einem Wikipedia-Artikel die Behauptungen eines Herstellers - als solche gekennzeichnet - wiederzugeben. (JM) --77.176.25.130 21:54, 28. Mär. 2007 (CEST)

Ist es nicht entscheidender, dass man mit MySQL Hochverfügbarkeit erreichen kann, wenn man es entsprechend dafür konfiguriert? Ich denke kein RDBMS bietet mit seinen Standardeinstellungen automatisch Hochverfügbarkeit. Hochverfügbarkeit wird man wohl z.B. mit MyISAM Tabellen nicht erzielen, und REPAIT TABLE gibts nur für MyISAM. Für InnoDB ist das unnötig.--JoeCrack 21:10, 1. Nov. 2007 (CET)

Partitionierung

Mir ist nicht klar, welchen Vorteil die Partitionierung überhaupt bringt. Im SQL-Manual findet man dazu auch keine Hinweise. Die Cluster-Technik braucht die Partitionierung. Aber was bringt die Partitionierung wenn man keine Cluster-Technik einsetzt? Ist es dafür da, damit man Daten auf unterschiedlichen Festplatten speichern kann? Oder ist es dafür da, damit Daten zusammenhängend gespeichert werden können? Das könnte man auch durch eine Datenreorganisation erreichen. Gibt es überhaupt ein Reorg-Tool bei MySQL?

Das sind so einige Fragen, die mir beim Lesen des Manuals nicht beantwortet wurden. Vielleicht kann mir jemand da einige Hinweise geben. --Julius-m 22:13, 7. Apr. 2007 (CEST)

Eine wichtige Anwendung ist, das partitionieren von zeitlichen Daten. Daten mit einer zeitlichen Nähe werden dadurch gemeinsam gespeichert, das heißt durch eine örtliche Nähe auf den Sekundärspeicher übertragen. Vorteile: Reduktion von IO-Zeiten bei Zugriff auf Daten im gleichen Zeitraum und Reduktion von Fragmentierung, wenn alte Daten archiviert werden, da alle Daten einer Partition vollständig gelöscht werden können. -- sparti 22:30, 7. Apr. 2007 (CEST)

Bei den meisten anderen RDBMS sind genau das die Vorteile der Partitionierung. Aber bist Du Dir sicher, dass das bei MySQL auch so ist? Im Manual ist zu lesen, dass die Speicherengines sich der Treiber des Betriebssystems bedienen, um auf die Festplatten zuzugreifen. Ich halte es für möglich, dass die Partitionen dann auch fragmentiert auf der ganzen Festplatte verteilt angelegt werden. Dann würde eine Partitionierung für die IO-Performance überhaupt keine Vorteile bringen. Und der andere Punkt, die Administration der Partitionen als Ganzes: das müsste man erst mal ausprobieren, ob das Löschen einer Partition bei MySQL auch wirklich schneller geht, als die Ausführung eines DELETE-Statements. Ich bin da sehr skeptisch.

Beim Lesen der Manuals werde ich den Eindruck nicht los, dass man sich hier in erster Linie darum bemüht hat, mit den anderen RDBMS mitzuhalten und möglichst viele Features zu implementieren, um die Professionalität von MySQL zu beweisen. Ob diese vielen neuen Funktionen (gerade bei der Partitionierung) auch wirklich Vorteile bringen und ob sie wirklich so funktionieren, wie die Syntax es vermuten läßt, das wäre für mich die große Frage. --Julius-m 10:55, 10. Apr. 2007 (CEST)

GUI

Könnte man im Artikel mal ein paar Sätze mehr über die GUI einbringen? Danke! -- Simplicius ☺ 23:59, 15. Mai 2007 (CEST)

Welche? Es gibt nicht die Oberflaeche fuer Mysql. -- sparti 00:54, 16. Mai 2007 (CEST)

Datenbankgrößenbeschränkung?

Moinmoin, ich weiß nich, ob das stimmt, aber ich hab mal gelesen, MySQL hätte eine begranzte Größe der Datenbank?? wenn das stimmt, wie hoch liegt diewse grenze?? oder ist sie im "alltäglichen" leben im inet nicht von bedeutung? -- thx schonmal gruß Mihawk90 16:49, 15. Nov. 2007 (CET)

Das ist wohl von der verwendeten Speicher-Engine abhängig. Bei BDB kann eine einzelne Tabelle alleine schon 256 Terabyte groß sein. Wie es bei den anderen Speicher-Engines aussieht, weiß ich nicht. --Julius-m 18:46, 26. Dez. 2007 (CET)

Prognose

Ich wage mal eine Prognose für derlei Datenbanken wie MySQL:
Aufgrund der geänderten Normvorgaben (Einführung von eine extra "information_schema"-Datenbank, die praktisch nicht manipulierbar ist, was Rechte und Sichtbarkeit betrifft, also praktisch ein offenes Scheunentor a la W....), werden sich Hacker aller Art, seien es Kleinkriminelle, Nachrichtendienste oder der Staat selbst, die erst mal herausfinden wollen, wo ein Hacking "lohnt" und wer über welche Datenmengen verfügt, über derlei Entwicklungen die Hände reiben.
Denn der Datenbankbetreiber hat keinerlei Möglichkeit, derart grundlegende und damit sensible Daten zu verbergen, ist es einem potentiellen Angreifer erst mal gelungen, sich Rechte als normaler(!!) Nutzer zu verschaffen.
Hat der Angreifer sich erst mal mittels information_schema davon überzeugen können, daß ein Zugriff auf diese Datenbank aufgrund der Datenfülle/-struktur lohnenswert sein könnte, spielt es dann keine Rolle mehr, mit welchen Sicherheitsstrategien die Datenbank versehen ist: DER STAAT und seine Behörden (aber auch andere Einbrecher!) haben es nicht nötig, mit elektronischen Mitteln zu hacken - die ergreifen die Daten - wenn sie dank "information_schema" wissen, da gibt es rein Mengenmäßig was zu holen - bei "Bedarf" physisch, z.B. im Rahmen einer Hausdurchsuchung unter irgendeinem Vorwand (und wenn es der berühmte "Behördenirrtum" ist, mit denen man schon zum wiederholten Male unbescholtenen Bürgern Sondereinsatzkommandos auf den Hals hehetzt hat, um sie einzuschüchtern oder auszuspionieren. Hat man die Daten erst, kann man sich noch hinterher brav entschuldigen für das Versehen ...) (Beispielsweise kann mittels informatrion_schema die Frage des Geheimdienstes aufkommen: "Warum betreibt der Herr xyz als Privatmann eine derart riesige Datenbank - das weckt unsere Neugier!", oder: Journalist A hat nur ne kleine Datenbank, da lohnts eher weniger, aber Journalist B hat eine sehr große, wie wir sehen können - da sollten wir unsere Kräfte darauf bündeln. information_schema-Daten sind nicht nur für die Performance der Datenbank selbst gut, sondern auch ideal für Hacker, die ihre Tätigkeiten "optimieren" wollen! )

Der Auslöser und das Trojanische Pferd (und die Ausgangsvoraussetzung für solche Machenschaften) sind diese "information_schema"- Daten, da sie sich extrem schlecht (d.h.: für den normalnutzer überhaupt nicht!) verbergen lassen.
Jeder halbwegs auf Sicherheit bedachte Administrator wird von derlei Produkten wie Mysql ab Version 5 also die Finger lassen.
Schade! Ich mag solche Verschlimmbesserungen nicht, wie sie leider immer mehr Mode werden!(Auch z.B. jetzt im Internet, wo immer mehr in Mode kommt, die Kommunikation der Menschen nur noch mit Anmeldepflichtigen Foren zu realisieren, wo nur noch derjenige zu Wort kommt, der gegenüber dem Provider seine sensiblen Daten offenlegt, ohne die Gewähr zu haben, daß damit kein Schindluder getrieben wird! - Von derlei "Entwicklungen" profitieren nur noch die Doofen, Gutgläubigen einseits (die manipiliert werden WOLLEN, und die Machtneurotiker andererseits (die die öffentliche Meinung manipulieren wollen), nicht aber das einfache, RECHTSCHAFFENE Volk, das seine Freiheit und informationelle Selbstbestimmung bewahren will! Schlußfolgerung:
IT-Technologie wird mehr und mehr zum Manipulations und damit Unterdrückungswerkzeug der Herrschenden gegen die Bevölkerungen, ihre zunächst demokratische Struktur wird von den Entwicklern und Normkommissionen mehr und mehr in Frage gestellt und abgeschafft, sodaß IT-Technologien mehr und mehr zum Ärgernis, ja zur Gefahr für die Freiheit der Bevölkerung verkommen.
Es ist abzusehen, daß sich die Bevölkerungen deshalb, nach anfänglicher Begeisterung für die immensen Möglichkeiten dieser Technologien, von ihnen abwenden, ja sie bekämpfen werden, aufgrund äußerst berechtigten Mißtrauens gegen die Normungsgremien und die Entwickler.
Der Fall MySQL beweist, daß diesbezüglich auch freie Software gegenüber proprietärer nicht wirklich eine neue Qualität darstellt, da ihre Manipulation BISHER in BEIDEN fällen bereits auf der Ebene der vorgebenden Normung erfolgt. (Die Einführung dieser information_schema-Daten erfolgte nach meinen Recherchen aufgrund der entsprechenden Veränderung der vorgegebenen Entwicklungs-Normen - man sollte weiterrecherchieren, welchen Einfluß Geheimdienste und Lobbys auf diese Schlüssel-Gremien haben ...
Mögliche Lösung im Falle MySQL: Ähnlich des Verhältnisses Star-Office/OpenOffice sollte eine "neue", freie Mysql entwickelt werden (auch wenn sie dann zwar nicht mehr der "Norm", aber dem Anwenderbedürfnis entspricht!), die dieses Merkmal "information_schema" NICHT mehr hat, oder ZUMINDEST dem Administrator administrativ nicht derart stark entzogen wie hier vorliegend.
Derzeit wird der geringe Fortschritt auf Ebene der besseren Performance erkauft mit einem langfristig unabwendbaren Desaster auf politisch-rechtlicher Ebene und damit auf dem Gebiete der vernünftigen Einsetzbarkeit. Die Einsetzbarkeit von mysql ab Version 5 ist nur noch für Behörden von Nutzen, privater Einsatz kann zu unkalkulierbaren Risiken führen, indem der Nutzer sich stärker als in den vorigen Versionen der Gefahr informationelle Begehrlichkeiten aussetzt, ja diese mit dem Einsatz derartiger Datenbanken erst provoziert(!!).

MySQL 5 ff. ist mit der Gratiseinladung "information_schema" nur noch die ideale Datenbank für den Überwachungsstaat und das Hackertum, nicht aber geeignet für die Anwendung unter fairen, freien Bürgern.
Meint Hella (falsch signierter Beitrag von 91.14.210.114 (Diskussion) 2. Mär. 2008, 15:29)

Grundsätzlich teile ich deine Gedanken zum Datenschutz, nur kann ich – von technischer Seite – nicht ganz nachvollziehen, was MySQLs information_schema damit zu tun haben soll.

Man kann zwar einen Benutzer für dieses nicht "entrechten", aber lt. Referenzhandbuch („Jeder MySQL-Benutzer hat das Recht, auf diese Tabellen zuzugreifen, allerdings nur auf diejenigen Tabellenzeilen, die sich auf Objekte beziehen, für welche er die richtigen Zugriffsberechtigungen hat.“) und nach meinen heutigen Tests sieht ein Benutzer in den dortigen Tabellen, eigentlich handelt es sich dabei um Views, genau nur die Daten die ihn betreffen. Beispiel: SELECT * FROM SCHEMA_PRIVILEGES; zeigt genau nur die Privilegien des Benutzers der gerade angemeldet ist, d.h. im techn. sauberen Fall lediglich meine eigenen.

Problematisch ist natürlich wenn man aus einer Anwendung mit dem Benutzer „root“ an der DB arbeitet. Wer aber seine Anwendungen so entwirft ist, im Fall des Falles, ohnehin selbst Schuld.

Die meisten MySQL-Server, zumindest die die hinter Web-Sites stehen, laufen auf localhost des Web-Servers, oder auf einem Backbone-LAN, das natürlich wirklich nur ein LAN sein sollte. Die einzigen IP-Ports die dazu − auf dem Web-Server − offen sein müssen sind 80 und evtl. 443. Wo bzw. wie soll da jemand von außen an den DB-Server rankommen? Zugegeben, es gibt da viele Dinge die man dabei missachten kann, aber das hat nichts speziell mit MySQL zu tun, sondern betrifft den viel allgemeineren Bereich Netzwerksicherheit.

Oracle hat auch ein SYS- und ein SYSTEM-Schema. Gleich zwei "Angriffspunkte"! Hast du dort auch deine Bedenken geäußert?

--Geri, 21:20, 19. Mär. 2008 (CET)

P.S.: Und dann dient der Beitrag auch nicht zur Verbesserung des Artikels, wozu Artikeldiskussionsseiten eigentlich da sind, ist damit hier fehl am Platz.

P.P.S:: Und ich verteile auch nur ungern Fische. --Geri, 21:33, 19. Mär. 2008 (CET)

800 Mio. bar?

"Als Kaufwert wird eine Milliarde Dollar genannt, 800 Millionen in bar, 200 Millionen in Aktienoptionen." Sowas kann ich nicht glauben. (Was sollen vor allem die Schweden mit Dollars? :)) Handelt es sich hier vielleicht um eine ungenaue Aussage? --Euku B ¿ 12:39, 18. Mär. 2008 (CET)

„For the full fiscal year, the Company reported revenues of $13.873 billion“, „gross margin for the full fiscal year was 45.2 percent”, „For the full fiscal year, net income was $473 million”. Damit sind zwar $800 Mio. nicht gerade aus der Portokasse zu begleichen, aber ich denke sie konnten dennoch genug "zusammenkratzen" um auf die Summe zu kommen. --Geri, 21:47, 19. Mär. 2008 (CET)

Mir geht es nicht darum, ob sie es sich leisten können. Kein Mensch bezahlt Beträge über 1000 € bzw. für Dollar über $100 in bar, wir reden hier aber über $800 Mio. Das steht da so selbstverständlich (ohne Zusatz), dass ich nicht glaube, dass sie Bargeld meinen, sondern einfach nur Geld. Wie soll man sich das vorstellen? Sun kommt mit einem gepanzerten LKW voller US-Dollar und Sicherheitskräfte aus den USA bei den Schweden vorbei? Worauf die dann erstmal zur Bank fahren, um das Geld einzutauschen? Da war man schon im Mittelalter weiter fortgeschritten. Darum würde ich die 800 Mio. einfach nur Dollar ändern oder wie heise zusammenfassen. --Euku B ¿ 11:46, 26. Mär. 2008 (CET)

"In bar" heißt nicht, dass das Geld als Münzen oder Scheine übergeben wird. Die 800 Mio werden sicher durch eine Überweisung von einem Giro-Konto zu einem anderen transferriert. 200 Mio werden ja in Aktienoptionen bezahlt. Da werden auch keine Optionsscheine als Papierstücke Übergeben, sondern - falls es sich um Wertpapiere handelt - diese Wertpapiere werden von einem Wertpapierdepot in ein anderes übertragen. Es gibt noch viele andere Möglichkeiten, wie solche Firmenkäufe bezahlt werden können: durch Warenlieferungen in einem bestimmten Wert, durch Austausch von Grundstücken, Nutzungsrechte von Lizenzen und Patente. --Julius-m 20:00, 3. Apr. 2008 (CEST)

en:Cash: „In bookkeeping and finance, "cash" refers to a current asset account, ...“ ist evtl. des Rätsels Lösung. --Geri, 23:25, 3. Apr. 2008 (CEST)

Support-Angebote

Ich finde, die Infos über Supportangebote von MySQL AB (die's ja auch gar nicht mehr gibt) sind nicht relevant für eine Enzyklopädie. Vorschlag: Diesen Abschnitt löschen und durch einen Satz ersetzen, z.B. "Sun Microsystems bietet verschiedene Arten von kommerziellem Support für MySQL an." --Tinu87 13:56, 12. Mai 2008 (CEST)

Dass der Support auch die "Haftungsfreistellung vor Schadensersatzansprüchen Dritter" beinhaltet, finde ich ungewöhnlich und daher erwähnenswert. --93.135.100.166 22:36, 8. Sep. 2008 (CEST)

Typo

Im Abschnitt "Speichersubsystem" ist ein Satz nicht vollständig: "Neben den Indexen liegt ein Hauptteil der Transaktionsverwaltung der Engines." Kann ihn selber nicht vervollständigen, wollte nur drauf hinweisen. (nicht signierter Beitrag von 79.219.103.170 (Diskussion | Beiträge) 11:56, 7. Mai. 2009 (CEST))

Wenn ich das richtig verstanden hab' ist da alles in Ordnung. Mir fällt kein Wort ein, was da noch (sinnvoll) passen würde. --Beiträge/85.16.114.36 16:15, 15. Jun. 2009 (CEST)

Speicherengines

Ich bin noch ein ziemlicher Datenbankanfänger aber die Enginges gehören meiner Meinung nach schon in den Artikel, da sich damit doch die Leistungsfähigkeit gut an die Anforderungen anpassen lässt. Bei einigen Aufgaben steht nur die Geschwindigkeit im Vordergrund, bei anderen auch die Sicherheit von Transaktionen oder Kompressionsverfahren um Speichersparsam zu archivieren.

Mir fehlt da sogar noch eine und zwar die "Brighthouse Engine" in der Liste. Hat es einen Grund, dass sie nicht aufgeführt ist?--Polli75 10:01, 24. Jun. 2009 (CEST)

Habe sie ergänzt. Danke für den Hinweis. Hättest Du doch auch machen können. --Julius-m 20:17, 1. Mai 2010 (CEST)

Zu detailliert: Speichersubsysteme / Engines

Gehört diese detaillierte Auflistung von Engines inkl. ihrer Funktionsweisen wirklich in einen enzyklopädischen Artikel? Reicht es nicht, die Engines im Abschnitt "Speichersubsysteme" aufzuführen und knapp zu erläutern, dass sich jede für ein anderes Einsatzszenario eignet? In der derzeitig vorliegenden Fassung bläht dieser Abschnitt den Artikel meiner Meinung nach zu sehr auf.(nicht signierter Beitrag von 87.160.57.98 (Diskussion | Beiträge) 19:10, 8. Aug. 2009 (CEST))

Der Abschnitt MyISAM ist länger als der Hauptartikel, das ist schon seltsam, aber Rest ist doch knapp genug, nicht? --Euku:^⇄ 19:18, 8. Aug. 2009 (CEST)

Ich wäre dafür, die ganzen Erläuterungen zu MyISAM in den Artikel MyISAM zu verschieben und hier nur einen Zweizeiler zu belassen. Siehe auch weiter unten meine Anmerkungen zum Inhalt der Erläuterungen (Deadlocks bei MyISAM) --Julius-m 20:55, 1. Mai 2010 (CEST)

Abschnitt: Einschränkungen

"# VARCHAR-Spalten können bis Version 5.0.2 maximal die Länge 255 haben, ab 5.0.3 ist eine Länge bis 65535 Zeichen möglich." Genau genommen hat ein VARCHAR eine Längenkennzeichnung von 2 Bytes, kann also 65535 Bytes lang sein. Wieviele Zeichen das sind, hängt nicht nur vom gewählten CHARSET, sondern auch vom konkreten Inhalt des Strings ab. Bei utf8 ist man mit 65535/3 als maximale Länge auf der sicheren Seite. -- Isotopp 13:07, 18. Jan. 2010 (CET)

Wurde in den Artikel aufgenommen. --Julius-m 21:20, 1. Mai 2010 (CEST)

Einleitung

Gehören die aktuellen Ereignisse - ohne sie abwerten zu wollen - wirklich in die Einleitung? Das betrifft sicher die Zukunft, jedoch wurde das Produkt bisher wenig davon beeinflusst als das die Information einen so promineten Platz verdient hätte. Nur mal so mein Gedanke beim Lesen. Gruß --Pantomime 08:30, 28. Dez. 2009 (CET)

Habe die Einleitung etwas gekürzt und dafür den Unterabschnitt Geschichte etwas erweitert. --Julius-m 21:11, 1. Mai 2010 (CEST)

Schreibung

Ein bis zum 12. Mai 2010 laufendes Meinungsbild könnte Einfluss auf diesen Artikel haben. Bitte schaut mal rein. -- grap 10:06, 26. Apr. 2010 (CEST)

Das bedeutet dann wohl, dass wir den Artikel umbenennen müssen in Mysql ??? --Julius-m 20:47, 1. Mai 2010 (CEST)

Nein, das Meinungsbild wurde abgelehnt. Es bleibt beim uneinheitlichen Status Quo. Eine Blamage nicht nur in Anbetracht des für die Änderung aufgebrachten Aufwandes.

Die NK sind da recht eindeutig: "Ausnahmen von dieser Regel [hirnlose Kleinschreibung von allem und jedem] können in solchen Fällen gemacht werden [...], wenn die unkonventionelle Schreibung eindeutig die üblichere Schreibung ist und diese den Lesefluss und Wortverbindungen nicht stört."

Es bleibt damit also alles beim Alten. -88.130.122.77 23:04, 6. Jul. 2010 (CEST)

Deadlocks bei MyISAM

Es stimmt einfach nicht, dass die Table-Locks von MyISAM Deadlocks unmöglich machen: Wenn Transaktion T1 Sätze aus der Tabelle A geändert hat und nun in der Tabelle B Änderungen vornehmen will, dann kann es sein, dass eine andere Transaktion bereits in B änderungen vorgenommen hat und schon darauf wartet, dass T1 wieder die Tabelle A freigibt. Genau das ist ein Deadlock, nur eben nicht auf der Ebene der einzelnen Datenzeilen innerhalb einer einzigen Tabelle, sondern auf der Ebene von mehreren Tabellen.

Die Erläuterungen zu MyISAM sind sowieso viel zu ausführlich. Ich wäre dafür, diesen ganzen Abschnitt zu entfernen und lediglich zu vermerken, dass MyISAM beim Schreiben keine Zeilen-Locks, sondern immer gleich Tabellen-Locks verwendet. --Julius-m 20:47, 1. Mai 2010 (CEST)

Jupp. Ich wollte schon umformulieren zu „verringert die Wahrscheinlichkeit von Deadlocks“, aber selbst das halte ich für fragwürdig. Also, ich entferne diese Aussagen zu Deadlocks, wer eine Quelle dafür findet, dass es wenigstens die Wahrscheinlichkeit verringert, möge das gerne wieder einfügen. --Leo141 12:52, 19. Mai 2010 (CEST)

Prima, dass Du die falsche Aussage entfernt hast. Trotzdem finde ich aber immer noch, dass dieser Abschnitt viel zu ausführlich ist, zumal es einen eigeben Artikel MyISAM gibt. Hier gehören alle detaillierten Erläuterungen hin. --Julius-m 22:54, 24. Mai 2010 (CEST)

Wo ist die Info für Laien?

Ich als Laie hätte mir im ersten Abschnitt des Artikels gewünscht, die Informationen darüber zu finden was MySQL überhaupt ist und wozu man es braucht. Der Artikel an sich ist zwar ewig lang, aber eben nur mit Fachsprache und -Information gefüllt mit denen ich als Laie nicht anfangen kann. Meiner Meinung nach geht hier der eigentliche Sinn einer Wikipedia verloren und ich werde nun weiter Googeln um eine Seite zu finden, auf der ich kurz und bündig erfahre was MySQL ist und wozu man es braucht!(nicht signierter Beitrag von 80.187.106.176 (Diskussion) 16:16, 12. Mai 2010 (CEST))

Der Erste Satz lautet: Der MySQL Server [ˌmaɪɛskjuːˈɛl] ist ein relationales Datenbankverwaltungssystem. Wenn Du nicht weist, was ein relationales Datenbankverwaltungssystem ist, solltest Du dem Link folgen. Es ist nicht sinnvoll in einem Artikel über das Produkt alle Informationen der verlinkten Artikel wieder aufzuführen. --P.C. ✉ 16:21, 12. Mai 2010 (CEST)

Bevor man hier von Beschwerde (→ Beschwerde) spricht, sollte man überhaupt einen Anspruch auf etwas haben. --Euku:^⇄ 23:35, 12. Mai 2010 (CEST)

Der Einzige der hier von Beschwerde schreibt, bist du ! (nicht signierter Beitrag von 88.130.118.147 (Diskussion) 21:58, 5. Jun. 2010 (CEST))

Hättest du dir den Link oben angeschaut, dann hättest du auch "Beschwerde an die Autoren" im Edit-Kommentar gelesen, das was ich aufgegriffen habe. Aber du darfst auch gerne nochmal behaupten, ich hätte es in den Raum geworfen, wahrer wird es dadurch nicht. --Euku:^⇄ 01:03, 6. Jun. 2010 (CEST)

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 (nicht signierter Beitrag von 83.129.52.2 (Diskussion | Beiträge) 15:19, 24. Dez. 2004 (CET))

Der zusammenhang zwischen den verschiedenen DBMS-Engines und den Tabellentypen ist nicht klar. Kann man auf die MyISAM-Tabellen auch nur mit der MyISAM-Engine zugreifen und bei den anderen Tabellentypen und Engines ebenso, ober auch in beliebiger Kombination? -- 82.135.37.138 14:57, 20. Mär. 2007 (CET)

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)

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. (nicht signierter Beitrag von 141.46.10.99 (Diskussion | Beiträge) 13:06, 17. Mär. 2005 (CET))

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. (nicht signierter Beitrag von 193.174.102.185 (Diskussion | Beiträge) 16:52, 12. Jan. 2006 (CET))

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. (nicht signierter Beitrag von 217.187.110.7 (Diskussion | Beiträge) 23:58, 13. Jan. 2006 (CET))

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)

Die Diskussion um die Foreign-Key-Unterstützung hat sich sowieso erledigt, da Foreign Key's Bestandteil der aktuellen Version (5.0) sind. Es wäre vielleicht noch zu prüfen, wie weit die Bugs (sorry: die Special-Features) in der Gotchas-Liste (S. Diskussionsbeitrag "Schwächen von MySQL") in der Version 5.0 noch gegeben sind. -- 82.135.37.138 10:44, 19. Mär. 2007 (CET)

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? (nicht signierter Beitrag von 85.181.44.188 (Diskussion | Beiträge) 22:49, 26. Okt. 2006 (CEST))

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)

Zeitlose Geschichte

Ist ausser mir noch niemandem aufgefallen, dass der Abschnitt Geschichte keinerlei Zeitangaben enthält, kein Datum, keine Jahresangaben? So ist das kein geschichtlicher Abriss. Es lässt keine geschichtliche Einordnung zu. Stammt die erste veröffentl. Version aus diesem Jahrtausend, dem letzten, oder dem vorletzten? Im Prinzip wäre da jede Spekulation drin. Ich kenne mich mit der Geschichte von MySql nicht SOO gut aus, erinnere mich allerdings, es mind. seit Jan. 2000 zu benutzen. (wg. Stellenwechsel zu diesem Datum)

maddes (nicht signierter Beitrag von 62.214.255.136 (Diskussion | Beiträge) 22:49, 16. Mär. 2007 (CET))

Danke für den Hinweis. Die Jahreszahlen habe ich ergänzt. -- 82.135.37.138 15:11, 20. Mär. 2007 (CET)

Web-Services

"Ein bevorzugtes Einsatzgebiet von MySQL ist die Datenspeicherung für Web-Services."

Ich würde hier nicht von Web-Services sprechen, sondern generell von "dynamischen Internetangeboten" o.ä. Der Begriff Web-Service ist mittlerweise zu sehr an SOAP/WSDL/UDDI gekoppelt. (nicht signierter Beitrag von 129.13.186.2 (Diskussion | Beiträge) 12:57, 12. Jul. 2007 (CEST))

Einheitliches Wording?

Einmal steht Speichersubsystem, dann Engine, dann Storage Engine. Ist irgendwie sehr inkonsistent - kann man sich vielleicht auf ein Wording einigen und das konsequent verwenden. Alternati Einleitung mit Speichersubsystem mit dem Verweis, dass es kurz Engine heisst und dann wenigstens nur Engine schreiben? --Supersymetrie 09:29, 4. Sep. 2009 (CEST)

geändertes Veröffentlichungsmodell / Version 5.5. milestone / Versionshistorie

Es sollte auch etwas über das Milestone Prinzip z.B. Version 5.5. geschrieben werden...ich selbst musste mir das gerade erstmal zusammen suchen was dieses Milestone für eine Bedeutung hat und wieso es da einen Sprung von 5.1.41 auf 5.5.x geben wird.

Ebenfalls sollte es eine Versionshistorie geben die es sonst bei vielen anderen Softwareanwenungen in der Wikipedia bereits gibt.

--LR 11:33, 26. Dez. 2009 (CET)

Aktuelle Version?

Der Wikipedia-Artikel listet 5.5 als die aktuelle MySQL-Version auf, MySQLs Downloadseite bietet 5.1.42 an. 5.5 wird als Milestone 2 bezeichnet und ist nicht GA, sondern noch experimentell. -- Isotopp 12:34, 18. Jan. 2010 (CET)

Abschnitt Geschichte: Cluster

Im dem Abschnitt "Geschichte" (Wieso grad dort?) heißt es: "Mit dem MySQL Cluster steht ein Tabellentyp zur Verfügung, bei dem die gesamte Datenbank im Arbeitsspeicher vorgehalten werden kann. Es wird synchrone Replikation zwischen allen Clusterknoten und Transaktions-Verarbeitung unterstützt, jedoch keine Volltextsuche." Das ist zwar sachlich richtig, aber nicht wesentlich im Zusammenhang mit Cluster. Cluster ist eine hoch verfügbare verteilte Datenbank EN:Distributed Database. Im Fall von Cluster bedeutet das, daß die Daten einer Tabelle auf mehr als einen Knoten verteilt vorliegen können. Transaktionen werden von einem Transaction Controller mit Hilfe von Two Phase Commit auf alle Clusterknoten so angewendet, daß der Zustand des Clusters durchgehend konsistent bleibt - etwas das manchmal auch etwas legär als Master/Master bezeichnet wird.

Daten werden (in MySQL Cluster für MySQL 5.0) redundant im Speicher von mindestens 2 Nodes gehalten (Genau genommen gibt es einen Konfigurationsparameter numberOfCopies dafür) und laufend transaktional auf Platte gedumpt. MySQL 5.1 hebt die Bedingung 'im Speicher' für Daten auf, Indices bleiben weiter resident im Speicher.

MySQL Cluster wurde ursprünglich von Ericsson als Teil eines Konfigurationsspeichers für GSM Switches entwickelt und wurde von MySQL mitsamt dem Entwicklerteam erworben. Auch heute noch ist einer der Hauptkundenkreise von MySQL Cluster die Telekommunikationsbranche, auch wenn Anwendungen außerhalb dieser Branche mittlerweile existieren. Die Ziel-Verfügbarkeit ist Five-Nines (99.999%) [5]. -- Isotopp 13:04, 18. Jan. 2010 (CET)

Begriff Datenbankverwaltungssystem

Ich finde die Bezeichnung "Datenbankverwaltungssystem" sehr verwirrend. Sucht man nach dem Begriff, landet man auf "Datenbank(system)". Dabei ist MySQL laut http://dev.mysql.com/doc/refman/5.1/de/what-is.html kein DBS, sondern ein Datenbankmanagementsystem (DBMS). Diese Information sollte doch schnell ersichtlich sein, zumal ich wohl nicht der einzige bin, der in diesen Artikel reinschaut, um herauszufinden, in welche Kategorie (DB? DBS? DBMS?) MySQL fällt. M.E. sollte der erste Satz lauten: "Der MySQL Server ist ein Datenbankmanagementsystem." (mit entsprechendem Link). Oder sehe ich das falsch? (nicht signierter Beitrag von 128.176.238.70 (Diskussion | Beiträge) 20:29, 30. Jan. 2010 (CET))

Name des Produktes

Im Artikel heißt es "Die Herkunft des Namens MySQL kann heute nicht mehr genau rekonstruiert werden. Seit 1996 wurden diverse Bibliotheken und Tools mit dem Präfix My geschrieben. Es wird spekuliert, dass der Name My der Tochter des Mitbegründers Michael Widenius vielleicht auch der Ursprung des Namens MySQL sein könnte, sowie SQL als Kürzel für Structured Query Language – Strukturierte Abfragesprache." und man verweist auf of MySQL. Dort heißt es wörtlich: "MySQL is named after co-founder Monty Widenius's daughter, My." Monty bestätigt das in is the project called MariaDB?: "We can't use the MySQL name as this is trademarked by Sun, and Sun has chosen to keep that trademark quite exclusive to itself. The name MySQL (just like the MyISAM storage engine) comes from Monty's first daughter "My". MariaDB continues this tradition by being named after his younger daughter. " Das läßt keinen Raum für "spekuliert" und klärt die Herkunft beider Namen im Detail. Im übrigen ist MaxDB nach dem mittleren Kind von Monty benannt, das Max heißt (EN:Michael_Widenius). -- Isotopp 12:42, 18. Jan. 2010 (CET)

Darauf wollte ich auch gerade hinweisen mit http://dev.mysql.com/doc/refman/4.1/en/history.html, als ich es ändern wollte hat es mich gewundert, dass sogar darauf referenziert wird und im Artikel was anderes steht. --129.206.163.159 12:03, 2. Sep. 2010 (CEST)

Oracle erledigtErledigt

Im Artikel finde ich einige male "Sun", sollte das nicht in "Oracle" geändert werden?--62.180.117.241 15:30, 4. Nov. 2010 (CET)

Nein, dass MySQL z.B. ursprünglich von Sun entwickelt wurde ändert sich nicht dadurch, dass es jetzt jemand anders entwickelt. --88.130.74.68 05:01, 2. Jan. 2011 (CET)

rethinkdb erledigtErledigt

http://www.rethinkdb.com/ ist eine auf SSDs ausgerichtete 3rd Party Storage Engine für MySQL. Könnte man aufführen, aber vielleicht auch gerade nicht weil noch nicht für den Produktiven (Enterprise-) Einsatz reif? 91.20.219.69 17:24, 31. Mär. 2011 (CEST)

Nur rethinkDB zu erwähnen wäre einseitige Werbung. Würde man die unfertige rethinkDB nennen, müsste man erst recht alle anderen vergleichbaren fertiggestellten Produkte aufzählen. So wie es aussieht gibt es da im Moment bessere als rethinkDB. --88.130.107.106 13:09, 13. Mai 2011 (CEST)

Engines anderer Anbieter erledigtErledigt

Der Abschnitt lädt scheinbar dazu ein, irgendwelche x-beliebigen Datenbankengines einzutragen. Mit der Zeit haben sich da teilweise scheinbar beliebige Einträge angesammelt. Wenn man das nicht anhand vernünftiger Kriterien einschränkt, können Anbieter hier beliebig Werbung für ihre Produkte machen. Für sowas ist Wikipedia nicht da, siehe auch WP:WWNI Punkt 3. Meiner Ansicht nach muss es zumindest eine bemerkenswerte Besonderheit geben, ein Alleinstellungsmerkmal, das die genannten Engines von irgendwelchen anderen Engines unterscheidet. Bei Engines, bei denen kein Alleinstellungsmerkmal ersichtlich ist, sehe ich keinen Grund sie hier zu nennen. Ich habe den Abschnitt eben entsprechend ein wenig aufgeräumt. --88.130.108.231 04:43, 20. Aug. 2011 (CEST)

Abschnitt "Einschränkungen" erledigtErledigt

Der Artikel enthielt bis eben diesen Absatz über vorhandene oder zumindest angebliche Einschränkungen in MySQL. Abgesehen davon, dass diese Aufzählung hoffnungslos veraltet ist, lässt sich in Ermangelung irgendeiner Quelle auch nicht nachprüfen, ob sie zumindest inhaltlich halbwegs richtig ist. Bis das geklärt ist, hab ich sie hierhin ausgelagert. --88.130.94.28 03:08, 1. Feb. 2012 (CET)

Die folgende Liste betrifft Version 5.0. In späteren Releases können einige davon weggefallen sein.

* VARCHAR-Spalten können bis Version 5.0.2 maximal die Länge 255 haben, ab 5.0.3 ist eine Länge bis 65535 Zeichen möglich.
* Datenzeilen (mit Ausnahme von [[Binary Large Object|BLOB]]- und TEXT-Daten) dürfen nicht größer als 8 KB sein.
* Die Beachtung von Fremdschlüssel-Beziehungen wird noch nicht von allen Speicher-Engines ausgeführt.
* Volltextindizes werden ausschließlich von der Speicherengine MyISAM unterstützt.
* Check-[[Constraint]]s werden akzeptiert, aber von jeder Speicherengine ignoriert.
* Die Zeit-Datentypen DATETIME und TIME (nicht aber TIMESTAMP) werden ohne [[Zeitzone]] gespeichert; als Zeitzone wird standardmäßig die Zone ausgewählt, in der der MySQL Server läuft.
* [[Datenbanktrigger|Trigger]] können keine Transaktionen abbrechen.
* Keine Unterstützung von Sequenzen. Eine ähnliche Funktion bietet eine AUTO_INCREMENT-Spalte.
* Keine [[Schema (Informatik)|Schemata]].

Abgesehen davon interessiert das eh keine Sau mehr, weil die Informationen eh total veraltet sind. Und wenn's hier steht kümmert sich ja eh keiner drum. --88.130.94.28 03:39, 1. Feb. 2012 (CET)

Was ist so toll an Partitionierung?

Ich finde es unverständlich, dass hier gerade das Thema "Partitionierung" so übertrieben ausgewalzt wird. Verglichen mit den anderen Features, die MySQL bietet, ist die Partitionierung doch eher so ein Nischending. Und solange noch nicht mal die wichtigen Features hier anständig erklärt werden, finde ich, muss erst recht nicht Partitionierung derart unangemessen breitgetreten werden. --88.130.96.57 04:47, 3. Feb. 2012 (CET)

Ich stimme dir zu. Diesen Abschnitt habe ich damals geschrieben, weil mich das Thema einfach interessiert hat. Aber wenn ich es mir recht überlege, dann könnte man den gesamten Abschnitt eigentlich auch wieder entfernen. --Julius-m (Diskussion) 13:30, 16. Nov. 2013 (CET)

Verwendungshäufigkeit

Abschnitt 1: „bildet die Grundlage für viele dynamische Webauftritte.“ Sollte man hier nicht die Wörter „viele dynamische Webauftritte“ durch „die meisten dynamischen Webauftritte“ mittlerweile ersetzen? Was meint Ihr? --Goldener Käfer (Diskussion) 18:13, 7. Okt. 2014 (CEST)

Scheinbar hat niemand was dagegen, dann mach ich das jetzt einfach mal :-)

--Goldener Käfer (Diskussion) 20:23, 10. Okt. 2014 (CEST)

"Viele" ist ein Mengenbegriff der eine Aussage nur über den Gegenstand selbst trifft und aus den Quellen im Abschnitt MySQL#Einsatzgebiete und Verbreitung abgeleitet werden kann, "die meisten" geht aber einen Schritt weiter und trifft auch eine Aussage zu allen konkurrierenden Projekten - was einer eigenen Quelle bedarf. --Vanger ^!–!? 05:12, 11. Okt. 2014 (CEST)

So gesehen haste auch wieder Recht... --Goldener Käfer (Diskussion) 19:17, 11. Okt. 2014 (CEST)

Der Artikel ist ja lieblos gemacht

Man merkt dem Artikel an, dass sich jahrelang niemand um ihn gekümmert hat. Das fängt schon mit der "Struktur" an. Da wurde tagesaktuell irgendwas hintendran geklatscht (MySQL AB gekauft, Oracle gekauft, neue Version erschienen). Einen vernünftigen Überblick, was MySQL kann und vor allem wie es funktioniert gibt der Artikel nicht mal ansatzweise.

Bis heute. Ich war mal so frei und habe den Text erstmal sortiert und ihm eine Struktur gegeben. Damit weiß man zumindest mal ungefähr, was einen erwartet. Außerdem habe ich eine Abhandlung zu den Interna der Abfragebearbeitung verfasst. Da kann man so viel zu sagen; das ist echt sophisticated, wie MySQL da vorgeht.

Das lässt sich sicher alles noch ein bisschen schöner ausdrücken, aber jetzt gibt es zumindest ein Grundgerüst, mit dem auch der Laie was anfangen kann. --88.130.65.195 06:21, 31. Jan. 2012 (CET)

Verwendung

Die Aufzählung der Firmen die MySQL im Einsatz haben ist veraltet. Mit viel Wohlwollen kann man das MySQL Kompatible Versionen nennen.--141.24.16.174 11:21, 8. Jul. 2014 (CEST)

Quellen veraltet

Die Quelle http://www.mysql.de/why-mysql/marketshare/ war veraltet (404) - habe sie bis auf Weiteres aus den Quellen gelöscht. Ist die genannte Seite evtl. nur umgezogen? Weiß jemand was darüber? --2A02:8109:83C0:1959:6DCF:B3E9:6365:5BC1 21:36, 8. Feb. 2015 (CET)