Group_Concat

[Waldis]

Guten Tag,

leider muss ich euch nochmal um Hilfe bitten.

Wir haben ein Skript, welches derzeit mit php/mysql läuft. Wegen Offline-Betrieb bau ich das derzeit auf eine lokale Access-Anwendung um.

Leider musste ich feststellen, dass das, was bei mySQL geht, nicht bei Access geht. 
Kann mir einer mal n Anstoß geben, was den unten stehenden sql-Code angeht? Wie wäre das in Access lösbar?

Code [Auswählen] Erweitern


SELECT veranstaltungen.veranstaltung,
    GROUP_CONCAT(DISTINCT klassen.klasse ORDER BY klassen .klasse_id SEPARATOR '\r\n')
FROM veranstaltungen
LEFT JOIN veranstaltungen2klassen USING (veranstaltung_id)
LEFT JOIN klassen USING (klasse_id)
LEFT JOIN starter USING (veranstaltung_id)
GROUP BY veranstaltungen.veranstaltung

Grundsätzlich soll das Programm alle Veranstaltungen laden. Jede Veranstaltung hat aber unterschiedliche Klassen (Jugend, Erwachsene, Altersklasse).
Die Veranstaltung2Klassen enthält die Veranstaltung-ID und Klassen-ID und dient zur Verbindung.

Um trotzdem alle Klassen in einem Feld anzuzeigen, wird Group_Concat mit Seperator genutzt.
So sieht das ganze derzeit aus:

Veranstaltung	Klassen	Teilnehmer
ABC-Veranstaltung	Jugend | Erwachsene | Altersklasse	105

Leider scheint es bei Access keine Funktion zu geben, die mir die Klassen in einem einzigen Feld verbindet oder?

Ich blick's leider grad kein Stück, Googlen hat mir auch nicht wirklich geholfen.
Wenn mir da einer die Augen öffnen könnte, wär ich sehr dankbar^^.
Allein die komischen Verschachtelungen der Joins sehen für mich sehr gewöhnungsbedürftig aus, wenn ich mir da die einfache Handhabung mit Left Join bei mySQL anguckt^^.

[Hondo]

Hallo,
GROUP_CONCAT ist ein Ausdruck von MySQL und funktioniert nicht in Access.
Ein Pendan gibt es nicht.

Mysql bietet dem Anwender die Möglichkeit bei Gruppierungen, Werte anderer Spalten z.B. kommagetrennt in einer Zeile auszugeben.

Möglichkeiten sind begrenzt, imho kannst du nur "Group by" verwenden.

Andreas

[Waldis]

Das dachte ich mir. :/

Leider reicht mir group_by hier nicht aus, weil das mehrere Joins sind.
Versuch mich grad an mehrwertigen Feldern. Zwar nicht das Wahre, aber sollte halbwegs klappen.

Aber danke für die Antwort. Dachte schon ich dreh durch, weil ich nichts gefunden hab.

[MzKlMu]

Hallo,
es gibt auch was für Access.
Siehe hierzu:
http://dbwiki.net/wiki/VBA_Tipp:_Liste_per_SQL_aufbauen

[Josef P.]

Hallo!

Ein Quergedanke: warum verwendest du nicht weiter MySQL und nutzt Access nur als Client?

mfg
Josef

[Waldis]

@MzKlMu: Danke. Guck ich mir mal an.

@Josef: Hmm, gute Frage^^.
Aber dann muss beim jeweiligen Nutzer ja wieder MySQL installiert sein oder? Das Programm muss an jedem PC benutzt werden können. Einzige was ich beilegen würde, wäre Runtime.

[Josef P.]

Kommt drauf an, wie du installiert interpretierst.
Wäre es denkbar, dass du eine zip-Datei mit dem MySQL-Dateien beilegst, diese in Anwendungsordner entpackst und z. B. beim Start des Clients auch den MySQL-Server startest? (Linzenzrechte sind natürlich zu beachten!)

[Waldis]

Weiß nicht, ob das für die alten Herren so einfach ist.
Und wenn nachher der MySQL-Server nicht startet... Aber ich dank dir für die Info. Evtl. nützt mir das doch mal was.

[crystal]

Hallo Waldis,

das ist genau ein Problem der Normalisierung. Was nutzt es mir, die Klasse in eine sep. Tabelle normalisiert zu haben (dies unter Nutzung einer zusätzlichen Tabelle!), wenn man z. B. bei einfachen Abfragen Riesen-Klimmzüge machen muss, um die 3 möglichen Klassen nebeneinander darstellen zu können, sofern das überhaupt immer klappt.

Als Pragmatiker tendiere ich dann immer zur De-Normalisierung, also im Beispiel in Tab. Veranstaltungen schlicht 3 Felder Klasse1, Klasse2 und Klasse3 zu führen. Die Werte dieser Felder können ja aus einer Klassen-Tabelle stammen.
Bei Abfragen, die nach bestimmten Klassen suchen, wird's dann etwas aufwändiger, weil man ja nicht weiß, in welchem der drei Felder die gesuchte Klasse steht. Also muss man in der WHERE-Klausel die Abfrage der drei Felder mit OR verknüpfen. Man könnte das pragmatisch auch lösen, indem man die 3 Felder im Formular zu einem zusammenfasst und abspeichert. Mit Like findet man dann wieder jede Klasse, egal in welchem Feld sie steht.

Normalisierung ist richtig und nötig, aber man kann sich damit das Leben auch schwer machen, solange es keine einfachen Methoden gibt, Fälle wie diesen zu lösen (z. B. mit Group_Concat).

[Waldis]

Hallo crystal,

die Möglichkeit, einfach 3 Felder zu erstellen nehme ich aber nur bei mir bekannten Klassen.

Es soll weiterhin die Möglichkeit geben, die Klassen selbst zu benennen und zu bestimmen. Somit könnte der Verein dann z. B. die Jugendklasse nochmal in Altersgruppen splitten, wenn es nur ein Fest ist und kein offizieller Wettkampf.
Damit gebe ich dem Verein mehr Freiheit beim Benennen und Bestimmen der Klassen, ohne dass ich da später nochmal an den Tabellen Hand anlegen muss, weil etwas fehlt.

Für eine unbestimmte Menge von Klassen kommt nur eine extra Tabelle in betracht, leider. Sonst hätte ich das zu Beginn natürlich so gelöst, wie du es eben beschrieben hast.

[crystal]

Hallo Waldis,

ganz klar ist dein Vorhaben noch nicht geworden.
Gibt es für eine Veranstaltung mehrere Klassen oder je nur eine (oder wenige)?
Macht es Sinn, jeder Veranstaltung beliebig viele Klassen zuordnen zu können? Wäre es nicht besser, die Klassen entweder strukturierter zu definieren oder z. B. weitere Felder einzuführen (Mindestalter, Art der Veranstaltung)?
Eine Beispiel-Liste wäre da hilfreich.
Vielleicht muss die Klassen-Tabelle in sich normalisiert bzw. systematisiert  werden, indem du zu jeder Klasse gewisse Attribute speicherst.  Wenn jeder Verein seine Klassen frei definieren kann, verlierst du doch komplett die Übersicht. Der eine nennt seine Klasse U14, der andere Unter14, obwohl beide dasselbe meinen. Das könntest du auch errreichen, indem du ein Freitext-Feld benutzt, denn auswertbar sind U14 und Unter14 kaum, es sei denn, du hättest ein Feld MaxAlter, in dem jeweils 14 steht.

Schließlich bleibt die Frage, was du mit diesem Klassen-Feld eigentlich machen möchtest. Dein Einwand,

Es soll weiterhin die Möglichkeit geben, die Klassen selbst zu benennen und zu bestimmen. Somit könnte der Verein dann z. B. die Jugendklasse nochmal in Altersgruppen splitten, wenn es nur ein Fest ist und kein offizieller Wettkampf.

spricht ja eher dafür, dass das Feld lediglich ein Info-Textfeld ist. Dann brauchst du auch keine Extra-Klassen-Tabelle, höchstens um die Eingabe zu erleichtern und fraglich ist dann auch, ob du für jede Veranstaltung dann mehrere Klassen brauchst.

Anhand deiner wenigen Beispiele wäre es m. E. vielleicht besser, die Veranstaltung selbst mit diversen separaten Attributen zu versehen, als einen Umweg über spezielle 'Klassen' zu gehen, z. B.
Typ: Fest, Wettkampf, Freundschaftsspiel, Grillfest, Versammlung usw.
Altersgrenze min. max.: 6, 12, 14, 99 usw.
Geschlecht: m, w, egal

Was macht (d)eine Klasse aus, welche Attribute hat sie denn?
Wäre es nicht sinnvoller, die Veranstaltung selbst zu spezifizieren, als erst eine Klasse zu definieren und diese dann der Veranstaltung zuzuordnen?
Wie würde ein Verein überlegen? "Wir machen einen Wettbewerb für alle Mädchen unter 14." oder "Wir machen unser jährliches Grillfest." oder "Wir müssen eine Mitglieder-Versammlung einberufen, um..."

Und wenn ein Verein eine Veranstaltung erfassen möchte, muss er sich dann erst Gedanken darüber machen, ob er eine passende Klasse schon definiert hat und/oder diese zunächst sichten?

All das sind nur so Gedanken, die mir durch den Kopf schiessen, weil ich deine Applikation und deine Fragestellungen an deine Datenbank nicht kenne. Nichts für ungut also.

[Waldis]

Der Verein legt eine Veranstaltung an und soll dort auswählen können, nach welchen Klassen z. B. die Rangliste gemacht wird.

Jugend/Erwachsene
Jugend/Damen/Herren
Jugend/Damen/Herren/Altersklasse

Oder auch ohne Klassen, also jeder gegen jeden.

Später sind dann Ranglisten für die einzelnen Klassen ausdruckbar.

Ich hab es jetzt aber erst mal mit Mehrwertige Felder gelöst.

[MzKlMu]

Hallo,

Ich hab es jetzt aber erst mal mit Mehrwertige Felder gelöst.

die haben auch ziemliche Tücken, wie Du noch merken wirst. Insbesonders bei Auswertungen.

Mehrwertige Felder sind ganz klassische n:m Beziehungen die man besser mit 3 Tabellen und 2 1:n Beziehungen gestaltet als mit mehrwertigen Feldern. Und die von Dir gewünschte Konkatenierung ist ja damit auch nicht gegeben.
Und soweit ich weiß, funktionieren die Mehrwertfelder bei Access aber nicht bei mySQL.

[Waldis]

Muss bei mySQL auch nicht funktionieren. Will ja aus der Webanwendung ne Accessanwendung machen. Und selbst wenn, müsste ich eben die Webanwendung ein wenig umschreiben, wobei das das kleinere Problem ist.

Ich werd jetzt mal gucken, wie das mit den mehrwertigen Feldern so klappt.

Ich beschäftige mich mit Access jetzt gerade mal eine Woche. Ist alles noch ein wenig kompliziert.

[MzKlMu]

Hallo,

Ich werd jetzt mal gucken, wie das mit den mehrwertigen Feldern so klappt.

Ich würde Dir dringend raten auf die Mehrwertfelder zu verzichten. Ich halte diese in einer Datenbank für überflüssig. Die klassische Lösung als n:m mit 3 Tabellen ist letztendlich einfacher.

Ich habe hier noch einen Link zur Verwendung von Nachschlagefeldern in Tabellen direkt, was ja in die gleiche Richtung geht. Nur dass die Mehrwertfelder in der Handhabung noch komplizierter sind. Man benötigt für eine Datenbank weder Nachschlagefelder (in Tabellen) noch Mehrwertfelder. Alles nur scheinbar einfacher.
http://dbwiki.net/wiki/Access_Anf%C3%A4nger:_Die_Nachteile_von_Nachschlagefeldern