Verständnisproblem: Distinctrow in der Praxis

[Christian Nennewitz]

Hallo.

Kann mir jemand ein sinnvolles Beispiel nennen, bei dem die Verwendung
von Distinctrow in einer Abfrage ein anderes Ergebnis bringt als
die Verwendung von Distinct?
Mir fällt einfach kein Anwendungsfall für Distinctrow ein.

Viele Grüße,
Christian Nennewitz

[Uwe Ricken]

Hallo Christian,

DISTINCTROW ist halt Access-Dialekt und hat überhaupt
nichts mit ANSI-Standard zu tun.

IMO liefert DISTINCT genau das gleiche wie DISTINCTROW
aber ich lasse mich auch sehr gerne belehren ;-)
--
Gruß, Uwe Ricken
MCP for SQL Server 2000 Database Implementation

GNS GmbH, Frankfurt am Main
http://www.gns-online.de
http://www.memberadmin.de
http://www.conferenceadmin.de
____________________________________________________
APP: http://www.AccessProfiPool.de
dbdev: http://www.dbdev.org
FAQ: http://www.donkarl.com/AccessFAQ.htm

[Juergen Frieling]

Hallo Uwe, Christian

Post by Uwe Ricken
IMO liefert DISTINCT genau das gleiche wie DISTINCTROW
aber ich lasse mich auch sehr gerne belehren ;-)

Natürlich fällt mir da jetzt nix _sinvolles_ ein aber bei

T1(Nr int)
T2(Nr int)
T3(Nr1 int, Nr2 int)

spucken diese beiden Varianten andere Daten aus, weil in T3 die Nr2 in den
Datensätzen variiert, aber nicht angezeigt wird (T2 brauch ich nur (glaub
ich) um nicht aus allen Tabellen Daten anzuzeigen - da war irgendwas):

SELECT DISTINCT(ROW) T1.Nr, T3.Nr1
FROM T2 INNER JOIN (T1 INNER JOIN T3 ON T1.Nr = T3.Nr1) ON T2.Nr = T3.Nr2;

Nur mal so zum nachbauen.


Gruss,
Juergen

[Uwe Ricken]

Guten Abend Jürgen,

ich habe bisher DISTINCTROW wie folgt verstanden:

- kommt in der Ergebnismenge mehrfach ein Datensatz
vor, der in allen Attributen gleiche Werte beinhaltet,
so wird er denoch nur einmal angezeigt

Post by Juergen Frieling
SELECT DISTINCT(ROW) T1.Nr, T3.Nr1
FROM T2 INNER JOIN (T1 INNER JOIN T3 ON T1.Nr = T3.Nr1) ON T2.Nr = T3.Nr2;

In dem von Dir gezeigten Beispiel (habe ich aber nicht
nachgebaut ;-)) würde dennoch lediglich einmal die
Kombination T1.Nr1, T3.Nr1 angezeigt

IMO ist das exakt das Gleiche wie DISTINCT ;-)
--
Gruß, Uwe Ricken
MCP for SQL Server 2000 Database Implementation

GNS GmbH, Frankfurt am Main
http://www.gns-online.de
http://www.memberadmin.de
http://www.conferenceadmin.de
____________________________________________________
APP: http://www.AccessProfiPool.de
dbdev: http://www.dbdev.org
FAQ: http://www.donkarl.com/AccessFAQ.htm

[Jörg Ackermann]

Hi,

Post by Uwe Ricken
IMO ist das exakt das Gleiche wie DISTINCT ;-)

Ganz neues Beispiel:

Tabelle Test

F1 String, F2 String, F3 String

F1 F2 F3
AAA BBB CCC
AAA BBB CCX


select distinct F1, F2 from test;

AAA BBB

select distinctrow F1, F2 from test;

AAA BBB
AAA BBB


Gruß

[Christian Nennewitz]

Hallo zusammen,

Post by Jörg Ackermann
F1 String, F2 String, F3 String
F1 F2 F3
AAA BBB CCC
AAA BBB CCX
select distinctrow F1, F2 from test;
AAA BBB
AAA BBB

Das Beispiel von Jörg liefert doch das gleiche Eregbnis als wenn ich weder
Distinct noch Distinctrow verwende, also:
SELECT F1, F2 FROM Test;
Oder?

Vielleicht mal anders gefragt: Hat jemals jemand von Euch bewußt
in einer praxistauglichen(!) Anwendung DISTINCTROW verwendet -
und wenn ja - wozu?

Hat Microsoft den Distinctrow-Befehl möglicherweise nur ein-
geführt, damit ich nächtelang nicht schlafen kann und mir die Haare
ausreiße wenn ich darüber nachdenke?

Sollte man Distinctrow ignorieren und so tun als hätte man nie
etwas davon gehört?

Fragen über Fragen...
Vielleicht kennt ja jemand die Antwort(en).

Viele Grüße und besten dank für die Klärungsversuche,

Christian Nennewitz
***@hotmail.com

[Jörg Ackermann]

Hi,

Post by Christian Nennewitz
Das Beispiel von Jörg liefert doch das gleiche Eregbnis als wenn ich weder
SELECT F1, F2 FROM Test;
Oder?

Zufall !

F1 F2 F3
AAA BBB CCC
AAA BBB CCX
AAA BBB CCX


select F1, F2 from test;
AAA BBB CCC
AAA BBB CCX
AAA BBB CCX

select distinct F1, F2 from test;

AAA BBB

select distinctrow F1, F2 from test;

AAA BBB
AAA BBB

Gruß

[Christian Nennewitz]

Hallo Jörg,

(Sorry, ich wollte das gar nicht per E-Mail senden, aber ich erwische immer
den falschen Knopf. :-)

ich mag Dir ja nur ungerne widersprechen, aber Dein drittes
Beispiel mit Distinctrow liefert genau das gleiche Ergegbnis wie
das erste 'ohne alles'.

Post by Jörg Ackermann
F1 F2 F3
AAA BBB CCC
AAA BBB CCX
AAA BBB CCX
select F1, F2 from test;
AAA BBB CCC
AAA BBB CCX
AAA BBB CCX
select distinct F1, F2 from test;
AAA BBB
select distinctrow F1, F2 from test;
AAA BBB
AAA BBB ?

Und dann wäre da ja auch noch die Frage nach der praxis-
tauglichen Verwendbarkeit.

Viele Grüße,
Christian Nennewitz

[Jörg Ackermann]

Hi,

Post by Christian Nennewitz
Und dann wäre da ja auch noch die Frage nach der praxis-
tauglichen Verwendbarkeit.

Da fallen mir zwei ein.

zB. Welche DS in Tabelle1 einer 1:n Beziehung
enthalten DS in Tabelle2 (Beispiel in OH)

und

Um beim Beispiel zu bleiben:

Tab1 Tab2
F1 F2 F1 F3
1 A 1 B
2 A 2 C
2 C

SELECT Tab1.F1, Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1;

Anfügen von Datensätzen nicht möglich

SELECT DISTINCTROW Tab1.F1, Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1;

Anfügen von Datensätzen möglich

Gruß

[Jörg Ackermann]

Hi,

"Jörg Ackermann" <***@gmx.de> schrieb:

Beispiel war nat. so Quatsch, da nur eine Tabelle
beteiligt ist.

Also nochmal:
Tab1 Tab2
F1 F2 F1 F3
1 A 1 B
2 A 2 C
2 C

SELECT Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1;

A
A
A

SELECT DISTINCT Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1;

A

SELECT DISTINCTROW Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1;

A
A

Hoffe, jetzt wird klarer.

Gruß

[Christian Nennewitz]

Hallo Jörg,

Post by Jörg Ackermann
Tab1 Tab2
F1 F2 F1 F3
1 A 1 B
2 A 2 C
2 C
SELECT DISTINCTROW Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1;
A
A

Ja, jetzt sehe ich, daß Distinctrow eine andere Bedeutung hat als
Distinct. Andererseits käme man mit

SELECT Tab1.F2
FROM Tab1 INNER JOIN Tab2 ON Tab1.F1 = Tab2.F1
GROUP BY Tab1.F2, Tab2.F3;

auch zu dem Resultat. Eine Notwendigkeit für die Benutzung von Distinctrow
scheint mir daher
nie (zwingend) gegeben zu sein. Aber bei MS-Produkten gibts ja immer viele
Wege die
zum Ziel führen.

Vielen Dank für Deine Hilfe,
Christian Nennewitz

[Christian Nennewitz]

Hallo Jörg,

Post by Christian Nennewitz
Eine Notwendigkeit für die Benutzung von Distinctrow
scheint mir daher
nie (zwingend) gegeben zu sein.

Da muß ich mir jetzt wohl selbst widersprechen.
Dein Beispiel mit dem Anfügen von Datensätzen geht wohl nur
mit Distinctrow und nicht mit Group By.

Das ist wirklich mal ein Argument, daß für die Benutzung
von Distinctrow spricht.
Schade, daß so etwas nicht in der OH drin steht.

Nochmals vielen Dank und viele Grüße,
Christian

[Karl Donaubauer]

Post by Christian Nennewitz

Post by Christian Nennewitz
Eine Notwendigkeit für die Benutzung von Distinctrow
scheint mir daher nie (zwingend) gegeben zu sein.

Da muß ich mir jetzt wohl selbst widersprechen.
Dein Beispiel mit dem Anfügen von Datensätzen geht wohl nur
mit Distinctrow und nicht mit Group By.
Das ist wirklich mal ein Argument, daß für die Benutzung
von Distinctrow spricht.
Schade, daß so etwas nicht in der OH drin steht.

Noch ein paar Anmerkungen und weiterführende Links:

Wie Acki gezeigt hat ist DISTINCTROW nicht ident mit
DISTINCT. IMO hat es folgende Zwecke:

1. Nur 1 DS je Primärschlüssel-Kombi bei INNER JOIN und
Auswahl von Feldern aus nicht allen involvierten Tabellen.
s. das Bsp. im Absatz zu DISTINCTROW bei
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k/html/acintsql.asp

2. Bei John Viescas habe ich mal folgenden Verdacht gelesen:
In Standard-SQL konnte man das, was DISTINCTROW+INNER JOIN
machen, per WHERE-Klausel + IN + Subquery veranstalten.
Access 1 konnte noch keine Subqueries. Deshalb hat MS JET damals
vermutlich die Erweiterung DISTINCTROW als Nothelfer spendiert.

3. Mit 1 und 2 zusammenhängend:
Die JET Query Engine hat manchmal recht eigenartig wirkende
Probleme, die Aktualisierbarkeit von Abfragen zu akzeptieren.
Einige einfache Varianten dieses Problems (meist wie o.a. bei
INNER JOINS) lassen sich mit DISTINCTROW beheben.
Jede Menge Beispiele dazu gibt's bei Google.

Nicht umsonst war DISTINCTROW bis A95 Standard in jeder Abfrage,
die mit dem Abfrage-Editor erstellt wurde.

s.a. meine Anmerkungen und Links zu DISTINCTROW im Vortragsskript
zu JET-SQL auf meiner u.a. Website/AEK/Downloads

[Peter Doering]

Hallo Joerg,

Post by Jörg Ackermann
Zufall !

Eben! Siehe unten.

Post by Jörg Ackermann
F1 F2 F3
AAA BBB CCC
AAA BBB CCX
AAA BBB CCX
select F1, F2 from test;
AAA BBB CCC
AAA BBB CCX
AAA BBB CCX

Die 3. Spalte gehoert nicht hin. Ansonsten ok.

Post by Jörg Ackermann
select distinct F1, F2 from test;
AAA BBB

Ok.

Post by Jörg Ackermann
select distinctrow F1, F2 from test;
AAA BBB
AAA BBB

Hier krieg ich:

AAA BBB
AAA BBB
AAA BBB

Ich hab das Beispiel noch um Tabelle Test2 erweitert:
Feld F1
AAA
AAA
AAA
AAA

SELECT Test.F1, Test.F2
FROM Test INNER JOIN Test2 ON Test.F1 = Test2.F1;

AAA BBB
AAA BBB
... (insgesamt 12 Reihen)

SELECT DISTINCT Test.F1, Test.F2
FROM Test INNER JOIN Test2 ON Test.F1 = Test2.F1;

AAA BBB

SELECT DISTINCTROW Test.F1, Test.F2
FROM Test INNER JOIN Test2 ON Test.F1 = Test2.F1;

AAA BBB
AAA BBB
AAA BBB


Gruss - Peter

[Michael Zimmermann]

Hallo!

Post by Christian Nennewitz
Kann mir jemand ein sinnvolles Beispiel nennen, bei dem

die Verwendung

Post by Christian Nennewitz
von Distinctrow in einer Abfrage ein anderes Ergebnis

bringt als

Post by Christian Nennewitz
die Verwendung von Distinct?
Mir fällt einfach kein Anwendungsfall für Distinctrow ein.

Mein Gott, macht ihr einen Umstand! ;-)

Das ist recht einfach:

Distinct unterdrückt doppelte Datensätze, die durch die
Feldauswahl entstehen. Die nicht in die Abfrage
aufgenommenen Felder werden nicht herangezogen. Bei
DistinctRow werden auch die nicht im Select genannten
Felder auf Gleichheit geprüft.

In ordentlich konzipierten DBen wird man in
Abfragen auf Tabellen keinen Unterschied bemerken,
da eine mit Primärschlüssel versehene Tabelle keine
zwei völlig identischen Datensätze enthalten kann
(übrigens eine Forderung der relationalen Algebra)
und daher Distincrow nie greift.

In Abfragen kann es aber zu identischen DS kommen. Wenn
darauf weitere Abfragen aufbauen, dann kann man einen
Unterschied merken:

NName VName
Müller Hans
Müller Hans (ein anderer)
Müller Karl
Meier Gustav

Select Distinct NName:

Müller (Hans, Hans und Karl)
Meier (Gustav)

weil Müller = Müller nur ein DS

Select DistinctRow NName:

Müller (die 2 Hänse)
Müller (Karl)
Meier (Gustav)

weil Müller = Müller und Hans = Hans, aber Hans <> Karl 3 DS

Gruß aus Mainz
Michael

[Karl Donaubauer]

Post by Michael Zimmermann
Mein Gott, macht ihr einen Umstand! ;-)

Joo, aber falsch. ;-)

Post by Michael Zimmermann
Distinct unterdrückt doppelte Datensätze, die durch die
Feldauswahl entstehen. Die nicht in die Abfrage
aufgenommenen Felder werden nicht herangezogen. Bei
DistinctRow werden auch die nicht im Select genannten
Felder auf Gleichheit geprüft.
In ordentlich konzipierten DBen wird man in
Abfragen auf Tabellen keinen Unterschied bemerken,
da eine mit Primärschlüssel versehene Tabelle keine
zwei völlig identischen Datensätze enthalten kann
(übrigens eine Forderung der relationalen Algebra)
und daher Distincrow nie greift.
In Abfragen kann es aber zu identischen DS kommen. Wenn
darauf weitere Abfragen aufbauen, dann kann man einen
NName VName
Müller Hans
Müller Hans (ein anderer)
Müller Karl
Meier Gustav
Müller (Hans, Hans und Karl)
Meier (Gustav)
weil Müller = Müller nur ein DS
Müller (die 2 Hänse)
Müller (Karl)
Meier (Gustav)
weil Müller = Müller und Hans = Hans, aber Hans <> Karl 3 DS

Naa, 4 DS. DISTINCTROW legt die 2 Hänse nie zusammen.

Exkurs:

Wenn die Abfrage nur diese 1 Tabelle enthält, also

SELECT DISTINCTROW NName FROM tblNamen

dann kommen nicht 3 DS sondern (alle) 4. Bei DISTINCTROW geht's
nämlich nicht um das Zusammenlegen von gleichen DS sondern
um das nur einmalige Darstellen jedes DS.
Bei nur 1 Tabelle ist das Ergebnis daher ident mit dem von SELECT
oder SELECT ALL. DISTINCTROW wird schlicht ignoriert.

Witzig wird's erst bei mind. 2 Tabellen.
Hier geht es analog um das einmalige Darstellen jeder DS-Kombination.
Dabei werden im Ergebnis aber immer nur DS jener Tabelle(n)
berücksichtigt, deren Felder im SELECT vorkommen.

Fügen wir zunächst eine Tabelle mit Brüdern hinzu, dann haben wir:

tblNamen
id
1 (Müller Hans)
2 (Müller Hans - ein anderer)
3 (Müller Karl)
4 (Meier Gustav)

tblBrueder
BruederId, id
1, 1 (Paul, Bruder von Müller Hans)
2, 2 (Max, Bruder von Müller Hans - ein anderer)
3, 2 (Moritz, Bruder von Müller Hans - ein anderer)

Wir verknüpfen geradeaus:
SELECT tblNamen.id
FROM tblNamen INNER JOIN tblBrueder ON tblNamen.id = tblBrueder.id

liefert 3 DS:
1 (-1, Hans - Paul)
2 (-2, Hans, der andere - Max)
2 (-3, Hans, der andere - Moritz)

SELECT DISTINCTROW tblNamen.id...

liefert hingegen nur die 2 involvierten DS von tblNamen:
1 (Hans)
2 (Hans, der andere)

Im Standard-SQL entspricht das

SELECT tblNamen.id
FROM tblNamen
WHERE tblNamen.id IN (SELECT tblBrueder.id FROM tblBrueder)

Wenn hingegen auch 1 Feld von tblBrueder im SELECT steht, z.B.

SELECT DISTINCTROW tblNamen.id, tblBrueder.BruederId...

ist der Zauber von DISTINCTROW dahin, entspricht es wieder
SELECT ALL und liefert alle 3 DS.

Dieselben Prinzipien gelten bei _mehr_ als 2 involvierten Tabellen.
Fügen wir eine 3. Tabelle mit Kindern der Brüder hinzu:

tblKinder
KinderId, BruederId
1, 1 (Kind von Paul)
2, 1 (anderes Kind von Paul)
3, 2 (Kind von Max)
4, 2 (anderes Kind von Max)
5, 3 (Kind von Moritz)

Wir erweitern obiges SQL-Bsp. und verknüpfen wieder geradeaus:
SELECT tblNamen.id
FROM (tblNamen INNER JOIN tblBrueder ON tblNamen.id = tblBrueder.Id)
INNER JOIN tblKinder ON tblBrueder.BruederId = tblKinder.BruederId

ergibt 5 DS:
1 (-1-1, Hans - Paul - Kind von Paul)
1 (-1-2, Hans - Paul - anderes Kind von Paul)
2 (-2-3, Hans, der andere - Max - Kind von Max)
2 (-2-4, Hans, der andere - Max - anderes Kind von Max)
2 (-3-5, Hans, der andere - Moritz - Kind von Moritz)

SELECT DISTINCTROW tblNamen.id...
hingegen liefert wieder nur die 2 involvierten DS von tblNamen:
1 (Müller Hans)
2 (Müller Hans - ein anderer)

Erweitert man um Felder der anderen Tabellen, ändert sich bei
einfachem SELECT nie etwas an der zurückgelieferten DS-Menge.
Anders mit:

SELECT DISTINCTROW tblNamen.id, tblBrueder.id...

liefert wieder 3 DS, nämlich die 2 Hänse mit den Brüdern, die Kinder haben.
Jede Hans-Bruder-Kombination aber nur einmal, egal wieviele Kinder
die Brüder haben:
1, 1 (Hans + Paul)
2, 2 (Hans, der andere + Max)
2, 3 (Hans, der andere + Moritz)

Nimmt man auch noch 1 Feld von der Kinder-Tabelle mit in's SELECT
ist der Zauber von DISTINCTROW wieder vorbei, alle 5 DS usw. usf.

(BTW Insiderjoke: André kaufst du mir das elaboriert als Artikel ab? ;-)

--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com
Datenbankprofis: http://www.dbdev.org

[Michael Zimmermann]

Hallo, Karl!

Post by Karl Donaubauer

Post by Michael Zimmermann
Mein Gott, macht ihr einen Umstand! ;-)

Joo, aber falsch. ;-)

Das ist erschütternd. Genau so wird es nämlich in den
meisten Access-Wälzern - auch solchen von
Microsoft Press(!) - beschrieben.

Da Du mein Vertrauen in das geschriebene Wort zerrüttet
hast, glaube ich *Dir* natürlich auch nicht mehr einfach
so ;-) Ich werde den ganzen Kram also einfach mal selbst
ausprobieren. Scheint ja die einzige Möglichkeit in
unseren finsteren Zeiten zu sein.

Post by Karl Donaubauer
[...]André kaufst du mir das elaboriert als Artikel
ab? ;-)

Seid in jedem Falle bedanket, Edler aus Wien, für Euren
obschon noch nicht elaborierten so doch trefflichen und
füglich die Gedanken anregenden Code, welchselbiger
ebensosehr, wie er mein Herz verdunkelte, meinen Geist
erhellte. ;-)

Devotissime e Moguntia salutat
Michael