sqlite - doppelte distinct abfrage

[bleicher]

Grüße,
angenommen man hat eine Tabelle, und braucht Übersicht über vertretene Werte in 2 spalten -

aus einer fragt man es mit SELECT DISTINCT spaltenname FROM tabellename ab

aber was macht man, wenn man gleich 2 spalten abfragen will, AUßER (wann wird denn endlich großes ß eingeführt^^?) eine zweite abfrage zu machen? ist es möglich die werte der zweiten mitabzufragen, wenn kein zusammenhang gegeben ist?
MFG
bleicher

[Dynamite]

Hi,
gib dochmal bitte ein Beispiel was Du machen möchtest.

Dann wird Dir auch geholfen:-)

Gruß
Dynamite

[bleicher]

Grüße,

gib dochmal bitte ein Beispiel was Du machen möchtest.

grobes Beispiel - tabelle mit autos und städten wo die angemeldet sind, ich will alle Automarken und alle Städte als Liste haben - wobei es Wurst ist welches auto wo angemeldet ist - gefragt ist wirklich nur die liste Städte/Auto

SELECT DISTINCT autos, stadt FROM tabelle gibt gar nix zurück , was kann man machen?
 MFG
bleicher

[Vinzenz Mai]

Hallo,

gib dochmal bitte ein Beispiel was Du machen möchtest.

grobes Beispiel - tabelle mit autos und städten wo die angemeldet sind, ich will alle Automarken und alle Städte als Liste haben - wobei es Wurst ist welches auto wo angemeldet ist - gefragt ist wirklich nur die liste Städte/Auto

das Autos und Städte nicht in Relation zueinander stehen, kann es daher nicht sinnvoll sein, diese in *zwei* verschiedenen Spalten der gleichen Abfrage zu haben.

SELECT DISTINCT autos, stadt FROM tabelle gibt gar nix zurück , was kann man machen?

Zwei getrennte Abfragen für zwei voneinander unabhängige Sachverhalte erscheinen mir hier sinnvoll. Wenn Du's unbedingt willst, verbinde beide durch eine UNION

SELECT DISTINCT  
    'Auto' Typ,    -- führe eine zusätzliche Spalte "Typ" ein, um zwischen  
                   -- Autos und Städten unterscheiden zu können  
    autos  
FROM  
    tabelle  
UNION  
SELECT DISTINCT  
    'Stadt',       -- hier können wir keinen Spaltennamen mehr vergeben, da  
                   -- bereits vorhanden.  
    stadt  
FROM  
    tabelle

Beim Verarbeiten der Ergebnisdatensätze kannst Du anhand des Wertes der Spalte "Typ" unterscheiden, ob es sich um ein Auto oder eine Stadt handelt. Ich würd's nicht so machen, nicht bei diesem einfachen Beispiel.

Freundliche Grüße

Vinzenz

[bleicher]

Grüße,
danke - ich weiß, ich habe es mit 2 anfragen gelöst - aber man will es manchmal einfach wsisen^^
MFG
bleicher

[Ilja]

moin,

danke - ich weiß, ich habe es mit 2 anfragen gelöst - aber man will es manchmal einfach wsisen^^

wenn du es genau wissen willst, nimm UNION ALL und nicht UNION, was hier falsch wäre und zu fehlerhaften ergebnismengen führen kann.

Ilja

[Vinzenz Mai]

Hallo Ilja,

danke - ich weiß, ich habe es mit 2 anfragen gelöst - aber man will es manchmal einfach wsisen^^

wenn du es genau wissen willst, nimm UNION ALL und nicht UNION, was hier falsch wäre und zu fehlerhaften ergebnismengen führen kann.

das ist ausnahmsweise nicht erforderlich, weil - wie im Thema (doppelte distinct) steht - nur die Listen der Städte und Autos gewünscht sind und daher doppelte Einträge nicht gewünscht sind. Die Spalte "Typ" sorgt dafür, dass kein gewünschter Datensatz (Autoname = Stadtname) verloren gehen kann.

Freundliche Grüße

Vinzenz

[Ilja]

moin Vinzenz,

das ist ausnahmsweise nicht erforderlich, weil - wie im Thema (doppelte distinct) steht - nur die Listen der Städte und Autos gewünscht sind und daher doppelte Einträge nicht gewünscht sind. Die Spalte "Typ" sorgt dafür, dass kein gewünschter Datensatz (Autoname = Stadtname) verloren gehen kann.

bedinkt, der typ sorgt dafür, dass es keine doppelten gibt zwischen autos und städte, die durch UNION gefiltert würden. aber das dbms prüft es dennoch und das ist nicht notwendig weil es einfach unnötig mehr last erzeugt. sprich UNION ALL ist schon die richtige wahl, auch wenn du recht hast, in dem speziellen fall sollten die ergebnismengen gleich sein. des weiteren besteht auch die latente gefahr, dass man den Typ weg nimmt und es dann zu den problemen kommen kann. wie auh immer, in dem fall ist UNION ALL das richtige, weil es dabei nie zu problemen kommt und es performanter ist.

Ilja