SQLite: Order für Group_Concat-Werte (Left Outer Join)

WulfmanGER

Commander
Registriert
Juli 2005
Beiträge
2.225
Hallo in die Runde,

ich hab hier ein SELECT mit LEFT OUTER JOIN wo Werte im GROUP_CONCAT nach Tabellen-Info sortiert werden müssen ;)

Tabelle sets:
Code:
idSet
1
2
3
[code]

Tabelle movie:
[code]
idMovie
546
563
73956

Tabelle setlinkmovie
Code:
idSet    | idMovie    | iOrder
1        | 73956        | 1
1        | 563        | 3
1        | 546        | 2

Folgende Ausgabe ist dann gewünscht:
Code:
idSet    | idMovie
1        | 73956,546,563

Wie man sieht: idMovie ist nicht nach iOrder sortiert. Es sollte so ausschauen: 73956,546,563

Das bisherige SELECT
Code:
GROUP_CONCAT(DISTINCT movies.idMovie) AS 'MovieTitles'
...
LEFT OUTER JOIN setlinkmovie AS setlink ON (setlink.idSet = sets.idSet)
LEFT OUTER JOIN movie AS movies ON (movies.idMovie = setlink.idMovie)

Das SELECT ist natürlich noch viel größer (entspannte 41 Zeilen ... die SQL-DB stammt von "Ember Media Manager" und möchte ich ein wenig für eigene Zwecke auslesen/weiterverarbeiten - daher kann ich die Tabelle nicht "umbauen" - das SELECT ist von der SQL-VIEW "movielist" - falls jemand auch EMM nutzt)

Ich hatte jetzt versucht ein ORDER einzubauen. Nach dem LEFT OUTER darf ich das nicht - klar - ORDER bezieht sich auf die ganze Abfrage. Jetzt hatte ich gesehen das man in GROUP_CONCAT ein ORDER einsetzen darf. Geht aber überhaupt nicht (vorallem auch sowieso schon falsch, weil ich ja eine anderen Tabelle ansprechen müsste). Vermutlich geht das nur in mySQL nicht in sqlite.

Hab hier nicht wirklich viel Ideen - die Abfrage stammt halt auch nicht von mir. Mein Plan war Ursprünglich das was mit dem SELECT ALLES abgefragt wird, mit 3 SELECTS zu machen - dann hätte ich den Part der hier betroffen ist anders gelöst. Dann hab ich aber diese VIEWS entdeckt und das dort fast alles abgefragt wird was ich brauche und den SELECT dann angepasst - bis auf diese Reihenfolge die falsch ist (ist aber auch im Original schon falsch - ich hab nur keine Ahnung wo das IM Tool genutzt wird - sonst würde ich den Entwickler auf den Fehler hinweisen das ORDER fehlt/falsch ist)

Grüße
 
ginge nicht ein

SQL:
SELECT * FROM ( SELECT mit 41 Zeilen und Joins ) ORDER BY xy
 
  • Gefällt mir
Reaktionen: RalphS
Bin jetzt nicht mehr 100% in sqlite drinnen, aber das S in SQL steht für Strukturiert und dazu gehören insbesondere die verschachtelten Abfragen.

Wenn ORDER BY nicht in Group_Concat oder in "irgendeinen" Abfragetyp paßt: SELECT xyz drumherum und da dann ORDER BY, wie @KeepCalm sagt.

Zur Veranschaulichung eine UPDATE TABLE:
SQL:
UPDATE mytable SET col1 = value1 WHERE id = 1;
ist funktional(!) identisch zu
SQL:
UPDATE
(
SELECT col1 FROM mytable WHERE id = 1
) table_alias
SET col1 = value1;
wobei table_alias prinzipiell unnötig ist, von einigen DBMS per Syntaxanforderungen aber angegeben werden muß.
In #2 wird buchstäblich die gesamte Tabelle aktualisiert, die für UPDATE angegeben ist.
#2 ist damit vollständig identisch zu dem, was ein Update auf einem VIEW macht, nur daß dieser nicht als solcher explizit definiert wurde.

#1 ist sicherlich zu bevorzugen, da kompakter, aber #2 funktioniert ebenfalls, und wichtiger als die exakte Form der Abfrage ist die Minimierung der Datenverarbeitung -- dh. unter anderem
(A) Filter so früh wie möglich; und
(B) ORDER BY so spät wie möglich.
 
KeepCalm schrieb:
ginge nicht ein

SQL:
SELECT * FROM ( SELECT mit 41 Zeilen und Joins ) ORDER BY xy
eher nicht oder sehe ich das falsch? Meine 41 Zeilen sind hier IM Sub-Select aber order by mach ich auf die Ergebnissmasse - das passt hier nicht. Ich brauch ja eine Sortierung innerhalb eines JOINS damit ich im GROUP_CONCAT (welches mehrere Zellen zusammenführt zu einer) die saubere Reihenfolge habe. Hier sortiere ich am Ende nur alle Zelle xy (also die Zelle "3,1,2" wird nach "1,2,3" liegen ... aber trotzdem wir die Zelle weiterhin "3,1,2" enthalten.

abcddcba schrieb:
Kurzum, die Reihenfolge in group_concat ist "beliebig", je nach Implementierung, halt ohne jegliche Garantie. Was man machen kann ist eine Window Function nehmen

explizit den nicht - aber schon andere in der Richtung. Das Teil wird mir ehrlich gesagt auch etwas zu komplex. Wollte jetzt kein SQLite lernen ;) ... nee ich hab keine Ahnung wie ich das auf die JOINs umsetzen kann. Allerdings hatte ich gestern schon versucht aus einem JOIN ein SELECT zu machen - mit dem Ergebnis das group_concat quasi alles an Daten reingepackt hat - irgendwo war da vermutlich ein Fehler ;)

Das mit dem SELECT werde ich aber mal noch mal verfolgen. Vielleicht gelingt es mir das JOIN zu seinem SELECT umzuformen

----

Mir ist aber gerade was was anderes eingefallen. Die Tabelle ist nur eine Arbeitstabelle und wird anschließend auf andere Tabellen aufgeteilt (ich sammel erstmal aus div. Quellen Daten und füge die Später zusammen). Daher auch ein GROUP_CONCAT mit Daten die ich zum sortieren natürlich separtiert haben muss. JEtzt übernimmt group_concat die Sortierung die ihm das JOIN vorgibt. Ich mach einfach ein zweites GC mit der iOrder-Spalte und schreibe das mit in die Tabelle:

Code:
IDs            |        iOrders
4,54,63,2    |        2,3,4,1
=> in php beides zusammenfügen:
4 => 2
54 => 3
usw. und dann so in die DB (jede ID bekommt eine Zeile) schreiben. Wäre natürlich schön wenn ich die Zelle direkt nach explode in die Ziel-Tabelle schieben kann - aber gut - ein Zwischenschritt ;)

Das mit dem SELECT klingt aber nach einer saubereren Lösung - teste ich auf jedenfall jetzt noch paar mal - allerdings mit irgendwelche WINDOW-Functions zu arbeiten - nee :(
 
Zurück
Oben