Nicht alle Einträge werden ausgegeben [SQL]

goto;

goto;

Erfahrenes Mitglied
Hallo liebe Community,
es geht darum, ich habe 2 Tabellen, in der einen sind Kategorien und in der anderen sind Unterkategorien.
Wie folgt sind beide aufgebaut.

name | categorie_id | parent_id

forum_categories
name categorie_id parent_id
x1 | 1 | 0
x2 | 2 | 0

forum_subcategories
name categorie_id parent_id
x1.1 | 1 | 1
x1.2 | 2 | 1
x2 .1 | 3 | 2

Wie folgt sollte es nun aufgebaut sein:
x1 = x1.1 , x1.2
x2 = x2.1

Mit folgendem Query mache ich die Abfrage:
SQL: 
SELECT
    *  
FROM
    (   SELECT
        parent_id,
        GROUP_CONCAT(DISTINCT name SEPARATOR ' ')  AS cats
        FROM
        forum_subcategories
    ) AS a
LEFT JOIN forum_categories
ON (forum_categories.categorie_id = a.parent_id)
Jedoch wird mir nur das resultat von der ersten Zeile aus forum_categories angezeigt.
Was mach ich denn falsch?
Danke im vorraus
 
Zuletzt bearbeitet von einem Moderator:
Wechsle mal auf RIGHT JOIN oder dreh die Reihenfolge deiner Taebllen um. Der Parent hat x Chieldren. Nicht umgekehrt. Ob es das Problem löst weiss ich gerade nicht, jedoch ist es definitiv falsch.
 
Moin Splater,

ein GROUP_CONCAT ohne GROUP BY würde sogar unsinnige Ergebnisse liefern,
wenn ich ihn implementiert hätte.
In deinem Fall fehlt also ein "GROUP BY parent_id".

Und wenn deine Datenstruktur nicht total zufallsbedingt ist, macht das DISTINCT keinen Sinn, außer vielleicht eine bessere Auslastung der Prozessoren.
Statt dessen soltest du lieber ein ORDER BY in die "Select ..GROUP_CONCAT"-Teilabfrage einbauen.

Kostet das Gleiche, bringt aber mehr Nutzen.

Grüße
Biber
 
Zuletzt bearbeitet:
Hallo, das hab ich gemacht. Auch eine RIGHT JOIN anfrage bringt mir ein Falsches ergebniss.
Hab es jetzt mal einfacher versucht. Nun sieht es so aus.
SQL: 
SELECT
forum_subcategories.name AS subcat, forum_categories.name AS cat, forum_subcategories.parent_id AS pid, forum_categories.categorie_id AS cid
FROM forum_subcategories
LEFT JOIN forum_categories
ON forum_subcategories.parent_id = forum_categories.categorie_id
Wenn ich nun mit GROUP_CONCAT arbeite, verbindet er zwar die Namen aus forum_subcategorie, jedoch verbindet er alle namen. Die Bedingung das parent_id = categorie_id wird also nicht mehr beachtet.
 
Zuletzt bearbeitet von einem Moderator:
Von der Subcategorie einen LEFT JOIN auf die catagory bedeutet, dass du pro subcategorie 0-n categories hast. Sollt es nicht umgekehrt sein?

SQL: 
SELECT
	forum_subcategories.name AS subcat, 
	forum_categories.name AS cat, 
	forum_subcategories.parent_id AS pid, 
	forum_categories.categorie_id AS cid
FROM 
	forum_categories
	LEFT JOIN forum_subcategories
		ON forum_subcategories.parent_id = forum_categories.categorie_id

Mit GROUP_CONCAT würde das dan so aussehen

SQL: 
SELECT
	s.cats, 
	c.name AS cat, 
	s.parent_id AS pid, 
	c.categorie_id AS cid
FROM 
	forum_categories AS p
	LEFT JOIN	(	SELECT
				        parent_id,
				        GROUP_CONCAT(DISTINCT name SEPARATOR ' ')  AS cats
			        FROM
				        forum_subcategories
				    GROUP BY parent_id,
			    ) AS s
		ON s.parent_id = c.categorie_id

Sollte es immer noch nicht gehen, liefere mal einen Dump der beiden Tabellen. Dann kann ich testen und nicht nur Theorie erzählen.
 
Zuletzt bearbeitet von einem Moderator:
Supi, jetzt klappt es. Hab es also falsch herum geschrieben :/ Werd mir mal noch ein Mysql Buch zulegen, wo soetwas beschrieben ist. Danke dir vielmals yaslaw :)
 
Hallo,

IMHO ist es besser, die Kategorien und Subkategorien in ein und die selbe Tabelle zu schreiben.

Das Auslesen über eine Schleife ist da dann wohl auch die bessere Lösung, als ein "übelst kompliziertes" Query zu bauen.

Sorry, dass ich nichts zur Lösung beitragen konnte, aber 2 Tabellen für diese Problematik anzulegen finde ich grundsätzlich schon den falschen Ansatz.

Viele Grüße und frohe Weihnachten,

Dirk
 
Hi Dirk,


DirkHo hat gesagt.:
IMHO ist es besser, die Kategorien und Subkategorien in ein und die selbe Tabelle zu schreiben.
Zum Vergrößern anklicken....

Achja, wie kommst du dazu? Noch nie etwas von Datenbank-Normalisierung gehört? (bis auf die 4 und 5 NormalForm wegen der Performence sollten alle Datenbanken i. d. R. normalisiert werden!)

Also wenn eine Subkategorie zu mehreren Kategorien passen würde, würdest du diese bei jeder Kategorie als Spalte hinterlegen? Wenn ja, hast du nachher übertrieben viel redundante Daten in der Datenbank!
Hast du schon mal daran gedacht, dass das Verwalten/Aktualisieren etc. der redundanten Daten unnötig viel Aufwand bedeuted, zusätzlich die Gefahr das man eine Stelle vergißt und an dieser dann noch die alten Daten "gammeln", oder mal an den total unnötigen Speicherverbrauch gedacht?

DirkHo hat gesagt.:
Das Auslesen über eine Schleife ist da dann wohl auch die bessere Lösung, als ein "übelst kompliziertes" Query zu bauen.
Zum Vergrößern anklicken....

Auch diese Aussage kann ich so nicht stehen lassen. Hier müsstest du mehrere Statements erstellen (was zeit/speicher kostet) und/oder jedes Statement erneut preparen (was auch zeit kostet), desweiteren ist das noch kein "übelst kompliziertes" Statement.

DirkHo hat gesagt.:
Sorry, dass ich nichts zur Lösung beitragen konnte, aber 2 Tabellen für diese Problematik anzulegen finde ich grundsätzlich schon den falschen Ansatz.

Viele Grüße und frohe Weihnachten,

Dirk
Zum Vergrößern anklicken....

Dann solltest du dich mal mit den Gründsätzlichen Ansätzen der relationalen Datenbanken auseinandersetzen!

Gruß
RudolfG
 
DirkHo hat gesagt.:
Das Auslesen über eine Schleife ist da dann wohl auch die bessere Lösung, als ein "übelst kompliziertes" Query zu bauen.
Zum Vergrößern anklicken....
Das Query hat im Formatierten zustand ja nur 14 Zeilen. Das ist noch weit weg von kompliziert, geschweige von übelst kompliziert (ab 50 Zeile aufwärts brauchts ein wenig mehr Konzentration zum lesen)

Grundsätzlich ist es fast immer schneller die Auswertungen mit einer Abfrage zu tätigen. Die Datenbank hat meist einen Optimizer der das SQL parst und selber aufgrund der Statistiken der Indexe eine schnelle Lösung generiert. Man kann den Optimizer unterstützen indem man bereits Sinnvolle Subqueries baut, Indexe anlegt und falls von der DB unterstützt regelmässig die Statisitiken updated.

Ich habe viel auf Performance-Verbesserung bei Oracle-Datenbanken gearbeitet. Glaub mir, eine übelst komplizierte Abfrage kann bis zu 10x schneller sein als eine enfache kurze Abfrage.

Darum: Nur Mut zu verschachteln SQL. Formatiert sie sauber, dann sehen sie auch nicht mehr so unübersichtlich aus.
Zuerst die Unterabfragen bauen - austesten. Dann alles zusammenfügen.
 
Zuletzt bearbeitet:
Hallo,

RudolfG hat gesagt.:
Also wenn eine Subkategorie zu mehreren Kategorien passen würde, würdest du diese bei jeder Kategorie als Spalte hinterlegen? Wenn ja, hast du nachher übertrieben viel redundante Daten in der Datenbank!
Zum Vergrößern anklicken....

Normalisierung ist mir natürlich ein Begriff. Mal abgesehen davon, dass es keine redundanten Daten gäbe, wäre das hier meiner Meinung nach die bessere Lösung (zumal er ja für die Tabelle Category keine parent_id bräuchte):

name | categorie_id | parent_id
x1 | 1 | 0
x2 | 2 | 0
x1.1 | 3| 1
x1.2 | 4| 1
x2.1 | 5| 2

Dann solltest du dich mal mit den Gründsätzlichen Ansätzen der relationalen Datenbanken auseinandersetzen!
Zum Vergrößern anklicken....

Das habe ich schon, wobei ich hauptsächlich mit O/R-Mappern auf die Datenbanken losgehe und da meistens kürzere Queries ausreichen... ;)

yaslaw hat gesagt.:
Das Query hat im Formatierten zustand ja nur 14 Zeilen. Das ist noch weit weg von kompliziert, geschweige von übelst kompliziert (ab 50 Zeile aufwärts brauchts ein wenig mehr Konzentration zum lesen)
Zum Vergrößern anklicken....

Naja, > 50-zeilige Statements habe ich wohl das letzte Mal im Studium geschrieben. Wobei ich es persönlich der Wartbarkeithalber angenehmer finde was kurzen zu lesen - ist aber wohl nur eine Frage, wie tief man in der SQL-Geschichte drin steckt.

yaslaw hat gesagt.:
Grundsätzlich ist es fast immer schneller die Auswertungen mit einer Abfrage zu tätigen. Die Datenbank hat meist einen Optimizer der das SQL parst und selber aufgrund der Statistiken der Indexe eine schnelle Lösung generiert. Man kann den Optimizer unterstützen indem man bereits Sinnvolle Subqueries baut, Indexe anlegt und falls von der DB unterstützt regelmässig die Statisitiken updated.
Zum Vergrößern anklicken....

Ok. Das war mir so nicht bewusst - wie gesagt, grundsätzlich verwende ich eher kürzere Queries, da mein Fall eher die Aufbereitung der Daten ist und da keine riesigen Datenbanken dahinter stecken.

yaslaw hat gesagt.:
Ich habe viel auf Performance-Verbesserung bei Oracle-Datenbanken gearbeitet. Glaub mir, eine übelst komplizierte Abfrage kann bis zu 10x schneller sein als eine enfache kurze Abfrage.
Zum Vergrößern anklicken....

Hehe, dann ist SQL ja deine 2.Muttersprache. Da kann ich dann doch nicht ganz mithalten ;)

Viele Grüße,

Dirk
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück