Firebirdforum.de

Die schnellste Methode für Inserts ist tatsächlich, den Prepare zu sparen. Dies erreicht man in der Verwendung von Parametermarkern. Dies gilt i.Ü. für alle DB's und alle Nicht-DDL-Befehle. Also "insert into mytable (?, ?, ?, ...., ?)". Dasselbe gilt eben auch für Update/Delete/Select. Der Overhead ...

Dann versuche das mal in der rekursiven CTE beim ersten Select.
Dass diese beim normalen union Select geht wissen wir doch schon;-).
Das ist dann aber eine spezifische Firebirdlösung die nicht mit jeder DB geht.

Nun, bei diesem Beispiel sehe ich keine Verwendung von NULL.
0 ist eine Konstante vom Typ int, so wie 0.0 eben double ist.

Wie gesagt, ich würde da auch keine Blöcke speichern, denn für Auswertungen ist das absolut unbrauchbar.
Ich glaube auch nicht, dass du mehrere 100 Messdaten/Sekunde bekommst.

Ich würde mir da auf jeden Fall Gedanken machen, ob dein Design dafür noch ausreicht. Blobs sind gut für Dokumente aber nicht für Daten. Wenn man sich überlegt, dass man bei kurzen Datensätzen (also wenige Felder) bis zu 3000 oder auch mehr Inserts per Sekunde erreicht, weiß ich ehrlich nicht, warum...

Ergänzend zu 1) Backuptools sind hier grundsätzlich vorzuziehen, da diese auch im laufenden Betrieb sichern können und kompaktere Outputs erstellen. Ein Copy scheitert fast immer, da in bereits kopierten Bereichen wieder Änderungen geschrieben werden die auf noch zu kopierende Bereiche massive Auswi...

Und gerade letzteres (root) funktioniert nicht ohne Typisierung.

Nach obiger Beschreibung der 3.x.
Da nun mal 4.0 nicht neu entwickelt wurde sondern eher auf 3.0 basiert, wird das Ergebnis logischerweise nich dem von 2.5ff entsprechen .

Bei mir klappts mit dem Union halt auch korrekt, wenn ich den NULL im 2. Unionblock typisiere. Es scheint eine spezifische Automatisierung von Firebird zu sein, die allerdings nicht SQL-Standard ist. Ähnliches erlebe ich auch beim SQL-Server was dann zu unnötigen Suchereien in den SQL's führt um ein...

Das kann ich natürlich nicht so stehen lassen.
Das Problem ist, dass "select null ..." nicht typisiert ist.
Aber

select cast(null as varchar(1)) from ...

funkioniert. Somit würde man auch kompatibel zu zukünftigen Versionen bleiben.
Zumal man dabei auch noch im SQL-Standard bleibt.