![]() |
Datenbank: ib • Version: 6.5 • Zugriff über: bde
distinct vs order by
hallo,
hab da mal ne frage...
SQL-Code:
liefert mir das gleiche ergebnis wie....
select distinct tabelle.feld
from tabelle order by tabelle.feld
SQL-Code:
gibt es pros und contras?
select tabelle.feld
from tabelle group by tabelle.feld order by tabelle.feld danke schon mal! |
Re: distinct vs order by
Nimm mal 2 Felder in die Feldliste, dann siehst du den Unterschied.
Das distinct blendet doppelte Werte(-mengen) aus, das Group By fasst diese zusammen. |
Re: distinct vs order by
annahme ich brauche nur ein feld?
|
Re: distinct vs order by
Dann würde ich trotzdem das erstere nehmen.
|
Re: distinct vs order by
Hallo,
Im Zweifelfall sagt der der ibplanalyzer, was schneller ist. Aber bei vielen Dubletten ist das auf jeden Fall das distinct. Ein order by kann schnell zum Auslagern auf die Platte führen. Heiko |
Re: distinct vs order by
Zitat:
btw...
SQL-Code:
liefert mir das gleiche ergebnis wie...
select distinct tabelle.feld1, tabelle.feld2
from tabelle order by tabelle.feld1, tabelle.feld2
SQL-Code:
select tabelle.feld1, tabelle.feld2
from tabelle group by tabelle.feld1, tabelle.feld2 order by tabelle.feld1, tabelle.feld2 |
Re: distinct vs order by
Hallo,
was mkinzler wohl meinte ist
SQL-Code:
gegen
select distinct field1, field 2
SQL-Code:
also ein "normales" zweites field im select
select field1, field 2
order by field1 group by field1 Noch zum distinct Ab 6.5 (?) ist der Index-Code auch noch komplett überarbeitet wurden, um mit bei vielen Dubletten besser / schneller zu sein. Heiko |
Re: distinct vs order by
Eine Gruppierung sollte von sich aus zu einer Sortierung führen. "Distinct" ist, praktisch gesehen, wie eine Gruppierung ohne Aggregatfunktionen.
Order By hat die gleichen Auswirkungen, die Distinct oder eine normale Gruppierung haben: Erst wird selektiert, danach werden die Werte gruppiert. Es muss also in fast[1] jedem Fall die Ergebnismenge zwischengespeichert werden, bevor sie zum Client geht. Wie man jetzt auf die Idee kommt, dass eine Sortierung schlimmere Auswirkungen haben kann verstehe ich jetzt nicht wirklich... :gruebel: [1] werden nur indizierte Felder benutzt sollte weder eine Sortierung noch eine Gruppierung "Nacharbeiten" erfordern. Schlicht und ergreifend weil Indizes nunmal sortiert sind. ;) |
Re: distinct vs order by
Hallo,
das Sortieren kann entweder direkt durch richtiges Durchlaufen eines Index erfolgen, oder durch Erstellen des Recordsets auf der Platte und Sortieren dieses Recordsets. Der 2. Fall ist langsamer. Ich habe das bei einem Kunden selbst erlebt. eine Query über 8 Tabellen mit einem Order By hat eine temporäre Tabelle von ein paar MB erzeugt. Das Recordset sind 13000 Einträge mit ner Menge Felder. Diese Query wurde auf mehreren Rechnern quasi gleichzeitig aufgerufen. In der Zwischenzeit war mit einem anderen Programm, welches auf die gleiche DB zugegriffen hat, praktisch nicht zu arbeiten. Nachdem ich das order by rausgenommen habe und die Liste lokal mit Quicksort sortieren, ist der Engpass weg. Heiko PS: Für das gleichzeitig konnte ich nichts, das wollte der Kunde so. |
Re: distinct vs order by
Zitat:
Man konnte in deinem vorherigen Beitrag herauslesen, dass dieser Performance hit bei Sortierungen aber nicht bei Gruppierungen/Distinct eintritt. Genau deshalb habe ich nachgehakt. Schließlich würde jegliches postprocessing zu genau dem Effekt führen (temp tabelle), egal ob Sortierung, Gruppierung oder Distinct. Ich bin übrigens auch der Meinung, dass man (wenn möglich) lokal sortieren sollte. Selbst DBMS'se, die normalerweise excellent darin sind Querypläne zu erarbeiten, generieren bei einer Sortierung den worst case (Indizierte Felder mal ausgenommen). edit: Mainung -> Meinung; auf was für'n Trip war ich denn da? :gruebel: |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:31 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz