mysql + maak array in query

[klaaslievens]

Dit is mijn probleem (eventjes vereenvoudigd in onderstaande omschrijving):
- ik heb een tabel met allemaal personen met een uniek id
- ik heb een tabel met verschillende groepen, waarbij één van de velden alle id's bevat van personen die tot deze groep behoren (bv. 1,3,7...)

Is het mogelijk om in één en dezelfde query de eigenschappen van de groep op te vragen, met meteen een array met alle namen van personen die tot deze groep behoren?
Het resultaat van die query zou dus iets moeten worden als volgt:
id_groep=1
naam_groep=verenigingX
leden_groep=array("Jan","Piet","Karel");

Ik kom er niet uit, dus alle hulp is welkom! Alvast bedankt!

 

[Frats]

Als een van de velden alle groepen bevat met comma seperatie (dus letterlijk 1 veld, 1 rij, en als waarde "1,2,3,6") dan wordt alles wat je doet lastig want dat is slecht design; je moet een koppeltabel maken met in elke rij het user_id en een van de groep_id, dan is een hoop mogelijk.

Arrays bestaan alleen in je programmeertaal, niet in SQL, dus die zul je op moeten bouwen uit de verkregen resultaten.

 

[klaaslievens]

Bedankt, Frats, voor je reactie. Totnogtoe heb ik het ook altijd zo gedaan, met een koppeltabel, maar ik vroeg me af of er een andere mogelijkheid was.
Ik begrijp niet helemaal waarom dit persé slecht design hoeft te zijn, hoewel ik dit inderdaad ook elders gelezen heb. Kan dit geen voordeel opleveren, als je (in mijn denkwijze) in één en dezelfde query alle gegevens kan ophalen? Vooral ook omdat die set "1,2,6" een onveranderlijke set is, en er bovendien, specifiek voor de toepassing die ik in gedachten heb, nooit meer dan 5 of 6 items in zo'n set komen te staan. Ik kan me eveneens voorstellen dat als je groepen krijgt met tientallen items, dat zo'n set dan heel onhandig werken is...

Ik kwam eigenlijk op deze denkwijze door de functie find_in_set(), vroeg me af of er iets dergelijks was die meteen items uit een andere tabel kon ophalen.

Met die koppeltabel moet ik dus sowieso 2 queries uitvoeren? Eentje die de gegevens van de groep ophaalt, met het groeps-id in de resultset, daarna eentje die in die koppeltabel op zoek gaat naar alle personen-id's die deze groeps-id hebben, eventueel gekoppeld aan een personentabel die meteen alle namen en zo ook ophaalt?

In ieder geval, ik kan nog alle kanten uit met mijn toepassing, ben nog maar bezig met nadenken over wat er allemaal nodig is en wat de toepassing moet kunnen, om dan bijhorende schetsen te maken van de DB-structuur...

 

[Frats]

Nee hoor, je kunt gewoon in 1 query alles ophalen.

Je huidige oplossing schaalt slecht, zoekt inefficient, is lastig te editen, en onmogelijk te indexen, en dat is gewoon niet handig. Het gaat echt tegen het idee van SQL in en het zal je alleen maar hoofdpijn opleveren vrees ik.

Als je in een keer in beide tabellen wil zoeken kun je het zo doen:

[sql]
SELECT *
FROM tabel_A
INNER JOIN koppel_tabel ON tabel_A.id = koppel_tabel.tabel_A_ID
INNER JOIN tabel_B ON tabel_B.id = koppel_tabel.tabel_B_ID[/sql]

Het enige is dus dat SQL altijd een vierkante array teruggeeft, dus rijen met kolommen, niet zoals PHP dat kan een array met verschilllende velden. Je kunt best alle data in 1x ophalen, maar je kunt het niet formatteren zoals jij wilt zonder PHP of een andere scriptingtaal.

 

[klaaslievens]

Dergelijke query kon ik zelf ook uitbouwen, maar die doet eigenlijk niet wat ik nodig zou hebben. Misschien moet ik mijn toepassing verduidelijken...

Het gaat om een toepassing als back-end, gekoppeld aan onze website, waarin ik klassieke concerten kan invoeren. Je hebt dus per concert een reeks gegevens, zoals datum, uur, locatie... en ik dacht ook aan een veld programma, met een set "1,4,5", waarbij elk cijfer verwijst naar het id van een repertoire-tabel. Klassieke muziekwerken kunnen soms lang duren, vandaar mijn opmerking in een vorige post dat er normaal gezien maximaal 5 of 6 items in één en dezelfde set zouden komen te staan, anders krijg je een concert van een ganse dag, wat dus nooit gedaan wordt...

Als ik een query zoals je hieronder aangeeft, gebruik, wordt mijn resultset als volgt (fictieve gegevens):
30/09/2010 - 20u - Amsterdam - Mozart, Concerto
30/09/2010 - 20u - Amsterdam - Beethoven, Symfonie
30/09/2010 - 20u - Amsterdam - Mozart, Divertimento

Zie je het probleem? Ik krijg eigenlijk dubbele gegevens die ik maar één keer nodig heb. Op de site en in het back-end wil ik gewoon een overzicht creëren als volgt:
Datum: 30/09/2010
Startuur: 20u
Locatie: Amsterdam
Programma: Mozart - Concerto, Beethoven - Symfonie, Mozart - Divertimento

Kan zoiets in één en dezelfde query? Want dat zie ik echt niet...

Bedoeling is wel dat ik achteraf kan opzoeken tijdens welke concerten bv. Mozarts divertimento (met id=6 bv.) gespeeld is geweest, maar dat kan via:
[SQL]select * from concerten where find_in_set(6,programma)[/SQL]

 

[Frats]

Je result-set klopt niet, je hebt de tabellen nog niet goed dan...

Je hebt een concert, met een plaats, datum, tijd

Voor dat concert heb je dan een aantal koppelingen met een concert_id en een muziekstuk.

Zoiets:

TABLE concert
INT id
DATETIME tijd_aanvang
VARCHAR plaats

TABLE concert_stuk
INT id
INT concert_id
INT plaats_in_concert
VARCHAR naam_stuk


Dat zal idd niet in 1 query gaan, maar dat hoeft ook niet. Je kunt de input van de gebruiker opbreken in meerdere queries, zodat hij het invult als 1x concert, plus 1x elk stuk maar achter de schermen zou je het echt op deze manier moeten doen.

 

[klaaslievens]

Helaas, maar ik had al zo'n vermoeden. Bij andere applicaties heb ik altijd met zo'n koppeltabel gewerkt, maar nu dacht ik het misschien eens anders te doen, gezien het beperkt aantal items in zo'n set.

Bij jouw 2de tabel-voorstel zou ik geen VARCHAR naam_stuk gebruiken, wel een INT id_repertoire, aangezien ik ook een tabel repertoire wil aanmaken. Detail...

Bedankt voor je feedback!

 

[Frats]

Ja id_repertoire is idd de volgende stap in de normalisatie, als je die informatie regelmatig nodig hebt is dat nog beter

Succes met je project!