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.

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.

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)

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)

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)