Diskussion:MySQL

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „MySQL“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Zum Archiv

Wie wird ein Archiv angelegt?

Automatische Archivierung

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 100 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 3 Abschnitte.

Defekte Weblinks

Dieser Baustein verhindert die automatische Archivierung dieses Abschnitts und seiner Unterabschnitte.

Die folgenden Weblinks wurden von einem Bot („GiftBot“) als nicht erreichbar erkannt.
Ausführliche Erläuterungen und Hilfe zur korrekten Behebung dieser Fehler finden sich auf Wikipedia:Defekte Weblinks. Ist ein von einem Bot als defekt gemeldeter externer Link doch erreichbar, dann bitte berichten – wie auch sonstige Probleme.

• http://dev.mysql.com/doc/refman/4.1/en/news-4-0-x.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.orghttp://giftbot.dwl.invalid/http://dev.mysql.com/doc/refman/4.1/en/news-4-0-x.html
• http://www.ddengine.org/versioneng
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.ddengine.org/versioneng
• http://dev.mysql.com/doc/refman/4.1/en/news-4-1-x.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.orghttp://giftbot.dwl.invalid/http://dev.mysql.com/doc/refman/4.1/en/news-4-1-x.html
• http://www.admin-magazin.de/content/moderne-mysql-forks-und-patches
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.admin-magazin.de/content/moderne-mysql-forks-und-patches
• http://dev.mysql.com/doc/refman/5.1/de/mysql-5-1-nutshell.html
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://dev.mysql.com/doc/refman/5.1/de/mysql-5-1-nutshell.html
• http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html
  • Vielleicht ist eine archivierte Version geeignet: archive.org * webcitation.orghttp://giftbot.dwl.invalid/http://www.mysql.com/news-and-events/sun-to-acquire-mysql.html
  • Artikel mit gleicher URL: MySQL AB (aktuell)
• http://www.tecchannel.de/server/news/1743838/
  • Vielleicht ist eine archivierte Version geeignet: archive.orghttp://giftbot.dwl.invalid/http://www.tecchannel.de/server/news/1743838/

– GiftBot (Diskussion) 16:55, 26. Nov. 2015 (CET)

Müsste MySQL nicht "Mü"SQL ausgesprochen werden?

Wenn der Name MySQL nach der Tochter namens "My" benannt ist, und der VOrname "Mü" ausgesprochen wird, müsste dann MySQL nicht auch "Mü"SQL ausgesprochen werden? (nicht signierter Beitrag von 62.206.54.18 (Diskussion) 16:58, 17. Mär. 2016 (CET))

Wie man den Vornamen ausspricht, weiß ich nicht. Selbst wenn der "Mü" ausgesprochen werden sollte, ist das bei "MySQL" anders. Über die Gründe können wir jetzt viel mutmaßen, was den Artikel ohne reputable Quelle nicht weiterbringt. Meine persönliche Theoriefindung ist, dass der Begriff deshalb "My" wie "mein" ausgesprochen wird, weil er im Englischen benutzt und "my" dort nunmal so ausgesprochen wird. --87.123.26.109 16:20, 22. Okt. 2016 (CEST)

Youtubevideo mit Widenius-Interview als Einzelnachweis für die Aussprache im Artikel ergänzt. Also Aussprache "mai". ---- (Diskussion) 13:24, 16. Nov. 2016 (CET)

ja das dachte ich auch. --Binbesser (Diskussion) 14:22, 4. Jul. 2023 (CEST)

oder gleich letter by letter: em, why, es, kyu, el. --Binbesser (Diskussion) 14:23, 4. Jul. 2023 (CEST)

Dieser Abschnitt kann archiviert werden. 87.123.4.206 12:15, 24. Nov. 2016 (CET)

Portabler Quellcode

Es geht um folgende Bearbeitung: [1] bzw. Edit-War. Quellcode ist immer portabel, da es sich dabei um ein Textdokument handelt. Ich kann auch auf meinem PC den Quellcode von jedem beliebigen Apple Programm ansehen und z.B. statische Codeanalyse darüber laufen lassen. Die Änderung ist somit auf jeden Fall falsch.

Wenn schon explizit unter "Plattformen und Schnittstellen" geschrieben steht, dass MySQL in C/C++ geschrieben ist, dann muss man auch erklären, was das mit Plattformen und Schnittstellen zu tun hat. Ergo die Erklärung, dass es deshalb nicht plattformunabhängig ist. Ich vermute auch, dass eine einfache "compilierung" eines einzigen Sourcecodes für viele Plattformen nicht reicht, da unterschiedliche Plattformen unterschiedliche Betriebssystembefehle zur Verfügung stellen, daher sich der Sourcecode auch je nach Plattform unterscheidet.

Auf jeden Fall gibt es keine Belege dafür, dass C/C++ aus Performancegründen gewählt wurde (ich vermute das stimmt, aber hätte gerne dafür Belege, da erwiesenermaßen C/C++ per se nicht schneller als z.B. Java ist, sondern dass Betriebssystembefehle damit leichter/schneller aufgerufen werden können). Ich habe deshalb mal den ganzen Satz enfernt. --Sebastian.Dietrich ✉ 08:20, 20. Feb. 2020 (CET)

Wenn das ihre Definition von Portabilität ist, dann wäre jedes Programm portabel. Man kann sich auch ein kompiliertes "Apple-Programm" auf Windows anschauen. Kompilierte Binärprogramme sind auch nichts anderes als Dateien mit wohldefiniertem Dateiformat. Es gibt auch Analysewerkzeuge für diese Dateiformate. Bei Linux ist z.B. ELF verbreitet. Unter Windows wird PE ("Portable Executable") verwendet, wenn man sog. ".exe" Dateien hat. Es gibt auch noch COFF u.v.m. Es kann bei dem Begriff Portabilität doch eigentlich nur um die Ausführbarkeit gehen, das anschauen einer Datei ist doch einigermaßen trivial.

Es gibt auch Softwarebibliotheken, die auf mehreren Plattformen verfügbar sind, sodass man dann ein Programm für mehrere Plattformen ohne Neuimplementierung kompilieren kann. Die JDK bei Java ist so eine Bibliothek, die auf mehreren Plattformen verfügbar ist. Diese enthält auch Plattform-spezifischen Code. Bei C ist die "C Standard Library" (libc) auf allen Plattformen verfügbar. Wenn man z.B. nur die libc verwendet, dann kann man ein C Programm für alle Betriebssysteme und Rechnerarchitekturen kompilieren, die eine libc anbieten. Und das sind de facto alle Betriebssysteme. Unter C++ ist die "Standard Template Library" auf allen gängigen Plattformen verfügbar. Bei MySQL ist die "libmysqlclient" die eigene Softwarebibliothek, welche die grundlegende Funktionalität der Datenbank anbietet. Wo gibt es eine Quelle, die beschreibt, dass es bei "libmysqlclient" Abhängigkeiten gibt, die plattformspezifisch sind? Man kann vom Prinzip mit den Standardbibliotheken von C und C++ bereits alle betriebssystemspezifischen Schnittstellen kapseln.

Ich finde die gänzlich gekürzte Version ganz gut, das enthält keine Spekulationen mehr. --Diaspomod (Diskussion) 10:19, 20. Feb. 2020 (CET)

Java ist aus technischen Gründen übrigens langsamer als C oder C++, wenn man die statistische Verteilung anschaut. Bei Java wird jedes Objekt (Reference Type) auf dem dynamischen Heap abgelegt, das vom Garbage Collector getraced werden muss. In C++ hat man die Möglichkeit, Objekte mit "unique_ptr" GC-frei auf dem Heap oder auf dem Function-Call-Stack abzulegen (RAII). Außerdem muss in der JVM jeder referentielle Funktionsparameter vom GC getraced werden, da es in Java kein Mechanismus gibt, der manchmal als "Borrowed Reference" bezeichnet wird. In C, C++ oder Rust gibt es das. Außerdem kann man in C, C++ oder Rust aggressiver "Inlining" betreiben. In Java ist jede nicht-statische Methode "virtual" und wird erst zur Laufzeit ermittelt. Dadurch können C oder C++ Programme potenziell den Cache effizienter nutzen. --Diaspomod (Diskussion) 10:40, 20. Feb. 2020 (CET)

Hi Diaspomod! Kannst ruhig du sagen - in der WP sind alle per Du.

@Begriff "Portabilität" - da bin ich ganz bei dir. Es geht nur um die Ausführbarkeit. Darum fand ich "der Quellcode ist portabel" so schrecklich, weil Quellcode nicht ausführbar ist (zumindest nicht bei compilierten Sprachen) und somit nicht "portabel" im Sinne "run everywhere" sein kann.

@Softwarebibliotheken - da bin ich nicht deiner Meinung: JDK ist das developer-kit und nicht portabel (du musst das JDK bzw. die JRE extra für deine Plattform runterladen). Was du meinst sind Java Programme (JARs, WARs, EARs) - die laufen ohne neu compiliert zu werden auf unterschiedlichen Betriebssystemen (da das compilat = Bytecode auf den jeweiligen JREs interpretiert/jit-compiliert/etc wird). Nur wenn man (was niemand wirklich macht) in Java mittels JNI auf C/C++ zugreift oder sonstige unübliche Dinge macht, dann sind Java Programme nicht portabel.

Die C standard library ist nicht dasselbe - das ist eine Library, die für viele Plattformen verfügbar ist. Ein ausschließlich mit der libc gelinktes C-Programm ist deshalb nicht portabel, es muss erst für die jeweilige Plattform compiliert werden. Wenn ich also mysql für Windows runterlade, dann wird es nicht auf einem Mac laufen - also ist MySQL nicht portabel, auch wenn es für viele Betriebssysteme Downloads gibt

@Java ist langsamer - das stimmte noch im Jahr 2000, ist aber inzwischen schon lange nicht mehr so. Die korrekte Antwort auf "Ist Java langsamer als C oder C++" ist "es kommt darauf an". Der Grund dafür ist, das all die Performanceoptimierungen, die es in C/C++ gibt rein statischer Natur sind. In Java (oder C# etc.) kann zur Laufzeit weitaus mehr bestimmt werden, was optimiert wird. z.B. machen GarbageCollectoren Speicher-Defragmentierung, wodurch kürzere Sprünge und Pointer möglich sind. Oder loop-unfolding, wenn bei einer Schleife zur Laufzeit nur wenige Iterationen nötig sind. Bei trivialen Microbenchmarks bringt sowas noch recht wenig, dennoch gabs schon 2003 Untersuchungen, bei denen sogar bei Microbenchmarks Java besser als C++ abschnitt (siehe z.B. https://shop.heise.de/katalog/daniel-dusentrieb oder http://scribblethink.org/Computer/javaCbenchmark.html). Und seit 2003 hat sich Java gerade hinsichtlich Performance noch deutlich gesteigert. C/C++ hat sicherlich seine Daseinsberechtigung bei hardwarenaher Programmierung wie z.B. embedded devices - da wird es auch performanter sein, aber ansonsten und insbesondere bei großen Applikationen ist man (auch) hinsichtlich Performance mit Java mit höchster Wahrscheinlichkeit besser dran.

Will darüber aber jetzt nicht streiten (da gab es immer schon Glaubenskriege). Beweisen lassen sich nur Performanceaussagen zu Microbenchmarks - auch das ist wesentlich komplexer als man annehmen könnte (auf Grund des "in die Gänge kommen" des Hot-Spot Compilers bei Java), lässt aber darüberhinaus keine Aussage zu Real-World Applikationen zu (wo die Performance meist nicht im Code, sondern in der DB oder der unpassenden Architektur verloren geht)

Aber da wir jetzt eh d'accord sind, was die gekürzte Version anbelangt, gibts eh nix zu streiten :-) --Sebastian.Dietrich ✉ 12:45, 20. Feb. 2020 (CET)

Dass man mit Java auch hinsichtlich Performance besser dran wäre halte ich für etwas zu tendenziös. Es gibt ja Gründe, warum Oracle seit Jahren am "Project Valhalla" arbeitet. Es gibt auch Gründe, warum die Sprache Rust von Mozilla angetrieben wird. Die Sprache C++ hat sich auch seit spätestens 2011 (C++11) modernisiert. Nur ist das Marketing-technisch noch nicht überall bekannt geworden. Es gibt Datenbanken wie MySQL auch in Containern, wie z.B. Docker. Diese Container sind plattformunabhängig, da sie z.B. auch direkt in Windows einsetzbar sind. In Zukunft ist eine Kompilierung in WebAssembly + WASI denkbar, dann hat man auch einen plattformneutralen Bytecode vergleichbar zur JVM. Es gibt nichtportable Quellcodes im dem Sinne, dass diese nicht portabel für mehrere Plattformen kompilierbar sind. Beispiel ist z.B. "systemd", das Linux-spezifische Schnittstellen nutzt, die auch nicht SUS- oder POSIX-konform sind. Aber ansonsten gibt es auch von mir keine Streitpunkte mehr. --Diaspomod (Diskussion) 13:16, 20. Feb. 2020 (CET)