Wenn nicht, gibt es keine unterschiedliche Struktur, dann brauche ich auch kein Union.
Zuerst wäre da die "gleiche Tabelle mit unterschiedlichen Where Clauses", das gehört m.E. in eine Abfrage mit geoderten Where Clauses.
"geodert" musste ich zweimal lesen
Du hast offensichtlich noch nicht mit großen Datenmengen gearbeitet, die im "where" ein "or" benötigen. Genau in solchen Fällen ist ein "union" (besser ein "union all") mit der/den selben Tabelle(n) durchaus sinnvoll, um Performance-Probleme zu vermeiden.
Aber auch dann halte ich ein "select *" nicht für sinnvoll.
geodert, ja, keine Geographie. Das nächste Mal nehm ich ein Bindestrich dazu
Naja, was ist groß? 2 stellige Millionenwerte ist mein Erfahrungshorizont, was Systene angeht, an denen ich entwickelt habe, ohne solche Konstruktionen, noch zu HDD Zeiten.
Und ich wüsste nicht, warum eine Engine ein OR schlechter behandeln sollte als ein Union (all).
Ich kann es auch anders formulieren:
Bevor man zu sowas greift, sollte man gründlich überlegen, welchen Aufwand es nach sich zieht (Codepflege), welche Risiken (Lücken in der Codepflege) und welche anderen Maßnahmen man ergreifen kann (Partitioning, Tuning, Optimizer Hints, ..) Kommt ja alles sicher auch etwas auf den Anbieter (oder Version) des
DB Sstems an. Und nur ums explizit zu sagen: Partitioning ist ja im Prinzip eine Art Union All, nur es erlaubt logisch einen transparenten Zugriff, trotz interner Aufteilung der Tabelle nach irgendwelchen Kriterien. Wenn die
DB das kann, warum soll ich es dann zu Fuß machen?