PHP sql met koppeltabel

[boomr]

Goedemiddag,

Ik zit met een opdracht voor school waar ik niet uit kom. Het gaat om het volgende:
Ik ben bezig met een vriendenboekje. Mijn code bestaat voornamelijk uit PHP en wat sql er tussendoor. Ik heb hier 2 tabellen en een koppeltabel. In tabel 1 staan personen, in tabel 2 dingen. De koppeltabel geeft aan welke personen in het bezit zijn van welke dingen. Tabel 1 heeft dus een primary key, tabel 2 ook en de koppeltabel maakt de koppeling tussen deze 2. Mijn koppeltabel heeft bestaat uit een primary key, en vervolgens 2 kolommen met de waarde van de primary keys van de andere 2 tabellen. dus zoiets:
Koppeltabel
Primary key Mensen dingen
1 1 1
2 1 2
3 2 1
4 2 4

Nu wil ik een overzicht maken van de mensen, met daarachter de dingen die ze hebben. Dit lukt me, maar wat me niet lukt is de mensen die meerdere dingen hebben maar één keer te laten zien. Ik ben zo ver dat dit waarschijnlijk met een for loopje moet, maar ik krijg het niet werkend. Iemand toevallig enig idee?

Ik kan mijn scriptje laten zien welke nu dus alle mensen en dingen laat zien, maar de mensen dubbel. Maar gezien dat enkel een while loopje is dat door de requltaten heen gaat en deze in een tabel zet heeft dat weinig nut lijkt me.

Ik hoop dat iemand me kan helpen. In ieder geval onwijs bedankt.

[emnich]

Gebruik GROUP BY in je SQL

[ Voor 59% gewijzigd door emnich op 06-01-2016 13:57 ]

[boomr]

emnich schreef op woensdag 06 januari 2016 @ 13:56:
Gebruik GROUP BY in je SQL

Dank je. Die heb ik ook geprobeert. Nadeel dan is dat de totale resultaten gegroepeerd worden. Betekend dus dat ik inderdaad maar een keer de specifieke persoon zie, maar de volgende resultaten dingen die daaraan hangen dus ook niet meer terug krijg.

[emnich]

Dus je wilt elk persoon maar één keer laten zien maar wel met alles spullen die het heeft?

Dan kan je evt GROUP_CONCAT gebruiken. Let wel op de beperkingen die het heeft.

[GlowMouse]

http://stackoverflow.com/...imary-key-on-a-join-table

[Verwijderd]

Als dit een schoolopdracht betreft lijkt mij het doel dat je dat zelf moet uitvogelen.
Eerlijk gezegd: dit is echt basis-kennis SQL, geen rocket-science.

[RobIII]

lj_tree schreef op woensdag 06 januari 2016 @ 13:55:
Mijn koppeltabel heeft bestaat uit een primary key, en vervolgens 2 kolommen met de waarde van de primary keys van de andere 2 tabellen.

Die PK is, in principe, overbodig. Je kunt gewoon een compound key maken van beide FK's in die koppeltabel.

lj_tree schreef op woensdag 06 januari 2016 @ 13:55:
Nu wil ik een overzicht maken van de mensen, met daarachter de dingen die ze hebben. Dit lukt me, maar wat me niet lukt is de mensen die meerdere dingen hebben maar één keer te laten zien.

Dan zul je eerst moeten definiëren hoe je dat zou willen zien: als ik een appel en een peer heb en jij alleen een appel:

UserID | Name         StuffID | Description     UserID | StuffId
-------|---------     --------|------------     ----------------
43400  | RobIII       1       | Appel           43400  | 1      
68020  | lj_tree      2       | Peer            43400  | 2      
                                                68020  | 1

Ervan uitgaande dat je dit in de query zou willen oplossen: Hoe wil je 't dan zien?

[b]A:[/b] [u]User      Stuff     [/]
   RobIII    Appel
   lj_tree   Appel

[b]B:[/b] [u]User      Stuff     [/]
   RobIII    Peer
   ls_tree   Appel

[b]C:[/b] [u]User      Stuff     [/]
   RobIII    Appel,Peer
   lj_tree   Appel

Want opties A en B zijn zoals een GROUP BY (Hoe werkt dat GROUP BY nu eigenlijk?) je dat zal gaan geven (afhankelijk van de exacte query krijg je dan een specifiek item X (appel, peer, iets anders...)). Je wil immers de gebruiker maar 1 keer weergeven en je kunt maar één waarde in kolom "Stuff" zetten.

Optie C is eigenlijk erg ongebruikelijk in SQL en ondanks dat er wel (meestal vieze) oplossingen voor zijn zoals GROUP_CONCAT zoals hierboven genoemd vind ik 't dan een beetje een vreemde schoolopdracht als je net nieuw met met RDBMS'en.

Wat echter, query-technisch, veel gebruikelijker is en vanuit 't oogpunt van een huiswerk opdracht ook veel logischer is een resultset zien te krijgen a-la:

[u]User      Stuff     [/]
RobIII    Appel
RobIII    Peer
lj_tree   Appel

...en dan vervolgens in je (PHP) code (inderdaad middels een (for) loopje o.i.d.) de weergave zo zien te genereren dat 't er uit ziet als:

[u]User      Stuff     [/]
RobIII    Appel,Peer
lj_tree   Appel

Om die resultset zo te krijgen gebruik je wat joins (zoals je zelf al waarschijnlijk gevonden had gezien je zegt "Ik kan mijn scriptje laten zien welke nu dus alle mensen en dingen laat zien, maar de mensen dubbel". Nou, daarna is 't gewoon een kwestie van even op papier uitwerken hoe je 't zou doen als jij 't met de hand moest doen:

code:

huidigenaam = ""
voor elke rij in de resultset {
  als huidigenaam != rij.naam {  // *zie opmerking hieronder
    huidigenaam = rij.naam
    schrijf nieuwe regel
    schrijf huidig
  }
  schrijf rij.product + ","
}

Zoiets en dan ben je een heel eind.

* Je wil dit niet op naam maar op UserID doen; er zijn meer hondjes die Fikkie heten (tenzij je een unique constraint op naam hebt staan). Daarbij wil je ook zorgen dat je altijd een ORDER BY gebruikt om er voor te zorgen dat alle rijen van users "bij elkaar" blijven (dus iets als: order by name, userid in je query opnemen).

[ Voor 30% gewijzigd door RobIII op 06-01-2016 15:04 ]

[boomr]

RobIII ik zit nog even flink door te rommelen maar hiermee lijkt het me wel werkend te krijgen. Alvast bedankt voor je erg uitgebreide hulp. Ik ga inderdaad voor scenario C.

[RobIII]

lj_tree schreef op woensdag 06 januari 2016 @ 15:39:
Ik ga inderdaad voor scenario C.

Maar dan hopelijk wel met de code-oplossing en niet de group_concat oplossing?

[emnich]

RobIII schreef op woensdag 06 januari 2016 @ 14:44:
[...]
Optie C is eigenlijk erg ongebruikelijk in SQL en ondanks dat er wel (meestal vieze) oplossingen voor zijn zoals GROUP_CONCAT zoals hierboven genoemd vind ik 't dan een beetje een vreemde schoolopdracht als je net nieuw met met RDBMS'en.

Is er een reden dat je GROUP_CONCAT een vieze oplossing noemt?

Zoals altijd met alles moet je weten wanneer je het wél en wanneer je het niet moet gebruiken maar ik zou niet weten waarom je principieel tegen zou zijn.

[ajakkes]

emnich schreef op woensdag 06 januari 2016 @ 16:31:
[...]

Is er een reden dat je GROUP_CONCAT een vieze oplossing noemt?

Zoals altijd met alles moet je weten wanneer je het wél en wanneer je het niet moet gebruiken maar ik zou niet weten waarom je principieel tegen zou zijn.

lj_tree in "PHP sql met koppeltabel"
Mijn code bestaat voornamelijk uit PHP en wat sql er tussendoor.

Ik denk, omdat dit een opdracht is met een focus op PHP, waarbij dit probleem vaker en ingewikkelder voor komt en dan meestal door PHP wordt opgelost.
Dan kan je dit wel uitvoeren door GROUP_CONCAT, maar daarmee heb je alleen geleerd dat het in sommige gevallen uitgevoerd kan worden met GROUP_CONCAT en hoe dit dan moet, maar wanneer het niet uitgevoerd kan worden met GROUP_CONCAT, weet je nog steeds niet hoe het moet. Terwijl, wanneer je het oplost in PHP je dit probleem en soortgelijke problemen wel kan oplossen in de toekomst.

[RobIII]

emnich schreef op woensdag 06 januari 2016 @ 16:31:
[...]

Is er een reden dat je GROUP_CONCAT een vieze oplossing noemt?

[list=a]
• Omdat 't een specifiek MySQL ding is (niet "ANSI-SQL" hoewel wel meer zaken dat zijn die ik desondanks toch gebruik); AFAIK kan geen enkel ander zichzelf respecterend RDBMS iets dergelijks (zonder trucjes). Je zult uiteindelijk toch niet eraan ontkomen 't te (leren) oplossen in de applicatie waar je 't ook hoort op te lossen.
• Omdat bij wat grotere groepen de inhoud afgekapt wordt en je potentieel dus zaken mist / niet ziet (zie group_concat_max_len, je kunt 't wat oprekken maar vroeger-of-later ga je tegen de limiet(en) aanlopen of je server nekken omdat je big-ass memory allocaties doet of je tempdb veel te zwaar belast voor iets onnozels)
• Omdat je dan een enkel veld met values + separator terug krijgt en dus zelf weer alles uit elkaar moet gaan pulken met een explode/split/whatever als je iets met die afzonderlijke waardes wil (gaan) doen (met alle gevaren van dien: wat als er in een waarde toevallig (ook) een separator char staat?)
• Omdat 't fucked met je datatypes (wat overigens onvermijdelijk is met een dergelijke functie): als ik een group_concat op ints doe krijg ik geen "array van ints" terug maar een string/blob die "ints" bevat gescheiden door een separator. Ints vallen misschien nog wel mee, maar probeer 't eens met een datetime, float of ander type; erg intuïtief is 't niet: weet je zonder proberen / documentatie erbij te sleuren hoe de datetime's gerepresenteerd gaan worden in het resultaat (yyyy-MM-dd? mm/dd/yy?)? Of floats (1.23 vs 1,23 waar je ook nog eens gevaar loopt met je separator in de knoei te komen als je niet van regional settings op aan kunt of specifiek forceert o.i.d. en/of specifiek de separator opgeeft etc.)
• Omdat ik 't gewoon persoonlijk een ontzettend ranzig vieze functie vind en ik gewoon lekker die mening heb omdat 't kan

[ Voor 44% gewijzigd door RobIII op 06-01-2016 19:01 ]

[emnich]

RobIII schreef op woensdag 06 januari 2016 @ 18:40:
[...]

[list=a]
• Omdat 't een specifiek MySQL ding is (niet "ANSI-SQL" hoewel wel meer zaken dat zijn die ik desondanks toch gebruik); AFAIK kan geen enkel ander zichzelf respecterend RDBMS iets dergelijks (zonder trucjes). Je zult uiteindelijk toch niet eraan ontkomen 't te (leren) oplossen in de applicatie waar je 't ook hoort op te lossen.

[off-topic]
PostgreSQL kan iets soortgelijks met string_agg en Oracle en DB2 kunnen het met LISTAGG. Enige discussie wordt dan of dat ook geen zichzelf respecterende RDBMS' zijn.

Voor de rest ben ik het met je eens maar dat zijn bekende beperkingen en als je die kent, zie ik geen reden om het niet te gebruiken zolang je er maar rekening mee houdt.

[Gomez12]

@TS : Wil je niet gewoon optie D van hieronder? Dan toon je de mensen met meerdere dingen nog steeds maar 1x?

RobIII schreef op woensdag 06 januari 2016 @ 14:44:
[...]

[b]A:[/b] [u]User      Stuff     [/]
   RobIII    Appel
   lj_tree   Appel

[b]B:[/b] [u]User      Stuff     [/]
   RobIII    Peer
   ls_tree   Appel

[b]C:[/b] [u]User      Stuff     [/]
   RobIII    Appel,Peer
   lj_tree   Appel

[b]D:[/b] [u]User      Stuff     [/]
   RobIII    Appel
             Peer
   ls_tree   Appel

Het is zo ongeveer hetzelfde als wat RobIII al als php-oplossing poste alleen dan gewoon iets niet afdrukken als ze gelijk zijn (namelijk de naam).

Dat is wat ik als veel normalere oplossing zie en gebruik. Dan blijft namelijk alles intact, ik heb bij een rapport niet een kolom die oneindig groot kan zijn (hij is nog steeds beperkt door de lengte van het stuff veld) wat je allemaal weer moet afvangen etc.

[RobIII]

Gomez12 schreef op woensdag 06 januari 2016 @ 20:37:
Dan blijft namelijk alles intact, ik heb bij een rapport niet een kolom die oneindig groot

Daar is een word/text-wrap voor en anders is 't een kwestie van de "newline" na elk item te echo'en; er varandert zo goed als niets aan de (pseudo) code die ik postte

[boomr]

Allemaal, en vooral ROBIII!! Heel erg bedankt. het is me gelukt. Achteraf was het inderdaad allemaal niet zo heel ingewikkeld en heb ik het mijzelf veel te moeilijk gemaakt door de code in eerste instantie kort te houden. Ik dacht dat alles in een enkele query moest maar dat hoeft dus helemaal niet. Ik heb nu 2 query's en een for loopje in een for loop. Werkt perfect.

Even wat achtergrond informatie:) Ik ben geen ontwikkelaar! Ik programmeer nooit. Ik kan wat simpele scripts lezen en powershell gaat me redelijk af, maar als ik zelf een nieuw script moet maken is dat vaak heel veel try and error! Met voornamelijk error:) Ik ben werkzaam als technisch beheerder en ben een jaar geleden begonnen aan een deeltijd HBO Bachelor opleiding. Het gedeelte programmeren is (gelukkig) vrij sumier, maar ik wil daar wel goed op scoren. En dat was zonder jullie hulp niet gelukt:)

Nogmaals: onwijs bedankt!

[RobIII]

lj_tree schreef op zondag 10 januari 2016 @ 11:48:
Ik heb nu 2 query's en een for loopje in een for loop. Werkt perfect.

Wat aan de late kant maar toch: je hebt nu toch niet zoiets mag ik hopen he?

code:

foreach $userrow in query("select userid, username from users")
{
    foreach $stuffrow in query("select stuffid, stuff from stuff ... inner join userstuff on ... where ...")
    {
       //Doe iets...
    }
}

Want daarmee vuur je dus count(users) maal de stuffquery uit (ofwel N+1 waarbij N het aantal users is) en heb je de bijbehorende overhead van de overbodige roundtrip naar het RDBMS e.d. er ook nog eens N keer bij. Dat is best wel not-done zeg maar

[ Voor 7% gewijzigd door RobIII op 14-01-2016 02:17 ]

[boomr]

RobIII schreef op donderdag 14 januari 2016 @ 02:16:
[...]

Wat aan de late kant maar toch: je hebt nu toch niet zoiets mag ik hopen he?

code:

foreach $userrow in query("select userid, username from users")
{
    foreach $stuffrow in query("select stuffid, stuff from stuff ... inner join userstuff on ... where ...")
    {
       //Doe iets...
    }
}

Want daarmee vuur je dus count(users) maal de stuffquery uit (ofwel N+1 waarbij N het aantal users is) en heb je de bijbehorende overhead van de overbodige roundtrip naar het RDBMS e.d. er ook nog eens N keer bij. Dat is best wel not-done zeg maar

Sterker nog: ik heb het nagenoeg exact zo:) Mijn docent heeft me uitgelegd dat het inderdaad voor veel meer verzoeken zorgt dan uiteindelijk nodig is, maar dit ook wel een vrij pittige was om mee te beginnen en hij al lang blij is dat het uiteindelijke resultaat werkt.

Eerste een for loopje die de gebruiker laat zien (disctinct) en in dat loopje een for loopje die de auto's voor die specifieke gebruiker ophaalt en laat zien. Betekend dus inderdaad dat voor elke gebruiker een query afgetrapt wordt. Maar gezien ik tot op heden nog maar 9 gebruikers heb is dat nog vrij goed te behappen:)

ALLES werkt. Er waren wat verplichte gedeelten en wat optionele gedeelten (uitdagingen) die voor een hoger cijfer gaan zorgen. Ik heb nu alles af. Enige wat me nog rest is de site wat netter maken. Het is nu qua layout een klein beetje rommelig en vrij saai. Moet nog wat met css gaat rommelen om alles netjes te krijgen en nog wat boeiende content toevoegen. En dan mag ik php rustig aan gaan vergeten:)

[redbullet]

Zit jij toevallig op het fontys in Eindhoven? Opdracht komt mij bekend voor

[boomr]

redbullet schreef op donderdag 14 januari 2016 @ 10:23:
Zit jij toevallig op het fontys in Eindhoven? Opdracht komt mij bekend voor

Lol. Ja! de avondopleiding ICT & Business. IWP op de woensdag.

jij?

[redbullet]

IWP op dinsdag avond opzicht was de opdracht niet zo heel moeilijk als je wist hoe je moest google / wat je nodig had

[Verwijderd]

*snip*, als je niet on-topic kunt reageren, reageer dan niet

[ Voor 80% gewijzigd door Woy op 08-02-2016 09:37 ]

[boomr]

Verwijderd schreef op donderdag 21 januari 2016 @ 17:31:
@ljtree: als je het zonder hulp niet kunt, dan raad ik je aan een andere school te overwegen.
Het is van de zotte dat anderen hier jouw schoolopdracht zitten te maken.

Ik heb wat hulp gevraagd bij een opdracht en dan vind je het nodig dat ik een andere school zoek?:) De opdracht is extra. Als uitdaging. Om wat meer te halen dan een voldoende. De rest is me allemaal netjes gelukt, bij deze zocht ik wat hulp. En dat heb ik gevonden. Nogmaals bedankt RobIII.

[Verwijderd]

*snip*, als je niet on-topic kunt reageren, reageer dan niet. Als je het niet eens bent met een topic doe dan een TR.

[ Voor 87% gewijzigd door Woy op 08-02-2016 09:37 ]

[Patriot]

Verwijderd schreef op donderdag 21 januari 2016 @ 19:19:
[...]

Zie je wel, het gaat erom dat wij hier jouw opdrachtjes voor school oplossen.
En sommigen hier zijn nog zo stom om dat te doen ook.

Oh please, hij is alleen geholpen. Jij hebt in je gehele schoolcarrière nog nooit een leraar of studiegenoot om hulp gevraagd? Ik mag hopen dat je op je werk niet zo'n zuigdruif bent die er op staat alles helemaal alleen te doen.

[Merethil]

Verwijderd schreef op donderdag 21 januari 2016 @ 19:19:
[...]

De eerste les die ik je zou kunnen leren is: lezen, goed lezen wat er staat.
Wat jij concludeert heb ik nimmer geschreven.

Achum:

@ljtree: als je het zonder hulp niet kunt, dan raad ik je aan een andere school te overwegen

Je zegt exact dat hij dan maar een andere school moet kiezen.

Daarnaast: hij stelt een vraag, heeft moeite gestoken in het eerst zelf proberen (dat kan je opmaken uit de TS), denkt mee en leert goed van de anderen en vindt uiteindelijk een antwoord.
Nee, het is misschien niet perfect, noch moeten wij huiswerk maken voor hem, maar zijn TS en inzet staat wel in de top 25% van vragen die ik hier zie langskomen.

Als je het trouwens zo nodig vindt niets toe te voegen en alleen op de persoon te bashen vanwege zijn wil om iets te leren en dat misschien niet helemaal te snappen van zijn docent (docenten zijn ook niet heilig he, genoeg die echt niet les kunnen geven, of zelfs niet eens een andere manier kunnen vinden van iets uitleggen als hun eerste uitleg niet werkte), dan zou ik als ik jou was gewoon niets schrijven, deze pagina sluiten en lekker verder leven. Als je niets aardigs of toe te voegen hebt, zeg dan niets.

[pedorus]

Offtopic:
Huiswerktopics zijn niet per definitie fout!
message 45570377

[ Voor 25% gewijzigd door pedorus op 21-01-2016 22:35 ]

[boomr]

Allemaal onwijs bedankt voor de hulp. Het is een 9 geworden. Helemaal tevreden mee:) Semester afgesloten met een 9 voor IWP en een 10 voor bedrijfseconomie. De oplossing was helemaal goedgekeurd:)

Over Csar, die heeft nogal de neiging om wat negatieve reacties te plaatsen:
DNS probleem
Live chat App/Plugin voor een CMS-site (Joomla)
En dat is dan pas van de eerste pagina van zijn reacties. Fear (mod van het audio topic) heeft al eens een reactie verwijderd met de tekst: NIET DOEN. Die is allerminst onredelijk over het algemeen!
Csar, ik zie dat je af en toe ook vrij nuttige reacties plaatst. hou het daar bij. Als je enkel reageert om je uit te kuren of af te reageren, doe het dan niet. Op facebook zijn pagina's genoeg waar norsheid onwijs gewaardeerd wordt:)

Nogmaals voor de rest: Bedankt!!!

[Woy]

Patriot schreef op donderdag 21 januari 2016 @ 19:57:
[...]

Merethil schreef op donderdag 21 januari 2016 @ 20:08:
...

pedorus schreef op donderdag 21 januari 2016 @ 22:19:
...

lj_tree schreef op maandag 08 februari 2016 @ 09:12:
...

Doe in het vervolg even een TR ( ) mocht je je aan een reactie storen, dan kunnen we daar als Moderators naar kijken. Dan kan het topic verder gewoon on-topic blijven.

[Verwijderd]

lj_tree schreef op maandag 08 februari 2016 @ 09:12:
Allemaal onwijs bedankt voor de hulp. Het is een 9 geworden. Helemaal tevreden mee:) Semester afgesloten met een 9 voor IWP en een 10 voor bedrijfseconomie. De oplossing was helemaal goedgekeurd:)

De vraag is nu wie er eigenlijk een 9 en een 10 hebben gehaald. Jij of de mensen op dit forum?

[b][message=45782453,noline]
Over Csar, die heeft nogal de neiging om wat negatieve reacties te plaatsen:

Ik ben niet negatief, ik vind dat je zelf je opdrachtjes voor school moet maken, anders heeft die school ook geen zin. Dat blijkt ook wel uit je reactie (de oplossing van de mensen hier is goedgekeurd).
Ik wil overigens best helpen als je er iets van leert, maar ik weiger jouw schoolopdrachten te maken.
Misschien moet de moderator daar ook eens beter rekening mee houden?