Tach!
Der erste SELECT erzeugt eine temporäre Table mit einer Row und Spaltennamen (View, Value). Bestimmt nicht.
Bestimmt doch, weil es keine physische Tabelle gibt auf die er sich beziehen kann. Ist natürlich alles im RAM des Servers, aber eine temporäre Tabelle MUSS es sein weil es ohne Table kein Resultset gibt.
Die Notwendigkeit, eine temporäre Tabelle zu haben, um ein Resultset erzeugen zu können, sehe ich nicht als zwingende Voraussetzung an. Es kann gut sein, dass das das interne Mittel ist, um Zwischenergebnisse auf dem Weg zum Resultset abzulegen, aber das kann genausogut eine andere Datenhaltung sein. Neben vielen anderen Möglichkeiten wäre auch noch eine, dass diese Datenhaltung als temporäres Resultset bezeichnet wird. Einträge im endgültigen Resultset oder temporären Zwischenspeicher können ja neben Tabellenfeldern nicht nur aus Konstanten sondern auch aus berechnten Ausdrücken entstehen.
Ich tue mich ja nur schwer, dem Kind einen Namen zu geben, den ebenfalls ein vorhandenes Ding verwendet, von dem wir gar nicht wissen, ob das zutreffend ist oder nicht. Am Ende entsteht durch die Vermutung nur eine neue Erwartungshaltung, die irgendwann zu Irritationen führt, weil sie in irgendwelchen Punkten nicht mehr zutrifft.
Für den Vergleich zwischen den Verhaltensweisen der Server müsste man noch berücksichtigen, dass ich das mit MS SQL Server gemacht habe und nicht mit MySQL. Wenn Du andere Feinheiten bei Typkonvertierung etc. erlebt hast, dann kann es sein, dass die beiden an der Stelle unterschiedlich spezifiziert sind, was nahelegt, dass dieser UNION über den standardisierten Teil von SQL hinausgeht.
Ich habe (bevor du dein Posting abgesetzt hast) ebenfalls MySQL mit MSSQL vergleichen und festgestellt, dass in dem Punkt Typkonvertierung die Systeme Unterschiede an den Tag legen. Aber das ist ja nichts prinzipiell neues, dass die DBMS in einigen mehr oder weniger großen Details unterschiedlich sind. Jedenfalls konnte ich deine Aussagen damit doch noch nachvollziehen.
MySQL konvertiert die Ergebnisspalte in einen String-Typ, sobald in einer der Zwischenergebnismengen ein String auftaucht. MS-SQL versucht hingegen, so wie ich das sehe, eine ähnliche Typkonvertierung wie beim Vergleich von Werten zweiter Typen. Kommt ein Zahlentyp im Ausdruck vor (sogar egal an welcher Stelle), wird versucht, den anderen Wert als Zahl zu interpretieren. Das gelingt dann auch bei Strings wie '42', aber nicht mehr bei '42w' oder gar 'foo'.
MS-SQL schreibt, dass die Typen "must be compatible through implicit conversion", Oracle hingegen formuliert "must be in the same datatype group (such as numeric or character)". PostgreSQL wiederum sagt "the corresponding columns have compatible data types, as described in Section 10.5.", und hat dann dort ein Regelwerk veröffentlicht. MySQL schreibt ausnahmsweise recht wenig brauchbares zu dem Punkt: "the types and lengths of the columns in the UNION result take into account the values retrieved by all of the SELECT statements. For example, consider the following:". Nach dem Beispiel kommt jedenfalls keine Erklärung, was das konkret zeigen soll. Das geht auch nicht aus ihm selbst hervor, weil nur unterschiedlich lange Strings miteinander vereint werden. Allen gemeinsam ist nur, dass die Anzahl der Spalten der Ergebnismengen der beteiligten Selects übereinstimmen müssen.
Meine Aussage zu "Unsinn oder nicht" bezog sich übrigens nur auf die grundsätzliche Idee, eine konstante Row und ein Resultset per UNION zu vereinigen. Die konkreten Besonderheiten wie unterschiedliche Spaltennamen oder mögliche inhaltliche Unsinnigkeiten der Werte habe ich dabei nicht betrachtet.
So habe ich die auch verstanden, als Antwort auf den generell vom Vormacher als Unsinn bezeichneten präsentierten Code, ohne diese Vorgehensweise anhand von konkreten Anforderungen beurteilen und bewerten zu können.
dedlfix.