mysql, uthenting data fra flere tabeller

[cipher]

hvordan hente ut en sånn her struktur på best mulig måte?

 

+ tabell1 (id, caption)

- tabell2 (id, caption, parent) (hvor parent refererer til en id i tabell1)

 

har sett på en slik her løsning:

 

$query1 = mysql_query("SELECT * FROM tabell1");

while($row1 = mysql_fetch_array($query1))

{

echo("<p>".$row['caption']."</p>");

echo("<ul>\n");

$query2 = mysql_query("SELECT * FROM tabell2 WHERE parent='".$row1['id']."'");

while($row2 = mysql_fetch_array($query2))

{

echo("<li>".$row2['caption']."</li>\n");

}

echo("</ul>\n");

}

 

men dette vil føre til like mange queries som det er rader i tabell1. Noen optimaliseringsforslag?

 

En annen mulighet jeg har snust litt på er å LEFT JOIN'e tabell1 da jeg SELECT'er fra tabell2, men dette vil føre til at radene fra tabell1 vil bli hentet ut for hver rad i tabell2. Liker altså ikke denne løsningen fordi den henter dataen flere ganger, og at den blir vanskligere å dele opp og plassere dataen riktig enn forrige løsning.

 

Noen forslag? Noen som vet hvordan større kommersielle systemer gjør det? Evt phpbb/invisionboard/o.l.?

 

Målet er å printe dataen slik:

 

tabell1 rad info

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

tabell1 rad info

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

tabell1 rad info

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

- tabell2 rad med tabell1 rad sin id som parent

 

Målet er altså å hente ut og formatere denne dataen raskest mulig med minst ressurs bruk på serveren.

Endret 16. januar 2004 av cipher

[Torbjørn]

løaningen din er ikke så gal. ellers tror jeg ikke det har noe å si at du henter ut tabell1 flere ganger med en left join, og det bør ikke være vanskelig å finne ut når du går over til en ny tabell1-rad (bare sjekke om du får ny caption?)

 

kan du relatere tabell1 og tabell2 mere direkte til din forumstruktur?

[cipher]

forumstruktur?

 

Uansett så er dette bare et teoretisk problem. Bare lurer på hvordan større systemer gjør det.

[????????]

forumstruktur?

 

Uansett så er dette bare et teoretisk problem. Bare lurer på hvordan større systemer gjør det.

Formstruktur - hvilke felter (navn og type) du har i tabellene, og hvilke felter som er matcher hverandre i de to.

 

Å Join'ne tabelle er vanlig, og det er det de fleste som bruker mysql gjør. Nå kommer snart versjon 4.1 av mysql hvor det er mulig å kjøre subquerys. Med den funksjonenen vil henteing av data (i litt mer avanserte databaser og spørringer) gå mye lettere.

 

Det er også viktig å bygge opp tabellene riktig. Ved å unngå dobeltlaring og opprette indexer på tabellene kan man forbedre hastigheten.

[cipher]

så du mener at de fleste faktisk join'er? dette er en løsning jeg absolutt ikke liker nettopp pga at jeg mener den da vil hente ut samme data flere ganger, og fordi det vil bli ekkelt å dele/forme/plassere dataen.

[Torbjørn]

ikke vær redd for joins!

 

kort sagt kan du si det slik: join's trenger du når alternativet ditt er å legge til flere kolonner i en tabell for å få det til å fungere.

 

eks en tabell over kunder og bestillinger. hvis du legger til kolonner bestilling1, bestilling2, bestilling3, etc.. etter hvert som kunden bestiller, har du et klassisk eksempel hvor du bør ha bestillingene i en egen tabell og bruke joins.

 

du kan godt hente ut en og en rad, og deretter for hver rad hente ut alle som har den som parent.

 

alternativet å hente ut hele røkla med en gang og sjekke når neste tråd begynner vil ikke være spesielt mye verre. jeg kan ikke si noe konkret om hastighetsproblemer, men regner med forumet skal være rimelig stort før det får noe å si.

[????????]

Hvis du har to tabeller, en med penner og en med mulige farger - f.eks.

 

Tabell 1

----------

1 - BIC - 49kr

2 - Pilot - 48kr

 

 

Tabell 2

----------

BIC - Blå

BIC - Rød

BIC - Sort

Pilot - Blå

Pilot - Sort

 

Tabell 1 inneholder pennene og info om pennene. Tabell 2 inneholder hvile farger de forskjellige pennene kommer i.

 

For å passe på at jeg ikke skriver noe feil lagde jeg et lite test script på nettopp disse tabellene. Ved å bruke LEFT JOIN brukte scriptet mitt under halve tiden, i forhold til å kjøre flere spørringer på databasen.

 

Test det gjerne du også!

 

Så da synes jeg det hjelper lite om du lagre et script som henter du "kun" den informasjonen du trenger, så lenge det tar lengre tid!

 

Hva er det du har i mot henting av data flere ganger? I verste fall kan du lage 2 spørringer, 1 som henter f.eks. info om pennne og en som henter f.eks. id til pennen (eller bare bruker den i ON) og alle mulige farger.

 

Å "dele/forme/plassere dataen" er vel ikke noe problem? Du bruker bare den dataen du vil ha, så mange ganger du vil!

 

Med MySQL 4.1 vil du slippe å hente så mye av den samme dataen!

[cipher]

ikke vær redd for joins!

 

kort sagt kan du si det slik: join's trenger du når alternativet ditt er å legge til flere kolonner i en tabell for å få det til å fungere.

 

eks en tabell over kunder og bestillinger. hvis du legger til kolonner bestilling1, bestilling2, bestilling3, etc.. etter hvert som kunden bestiller, har du et klassisk eksempel hvor du bør ha bestillingene i en egen tabell og bruke joins.

 

 

Er slik jeg bruker det nå og det virker bra på 1 til 1 "relasjoner", men liker ikke tankegangen da det gjelder 1 til mange "relasjoner".

 

Eksempelet mitt er jo på sett og vis en 1 til mange relasjon selv om det er lagt opp på en litt mer custom måte enn man er vant til enn fra f.eks. ms access o.l.

 

 

du kan godt hente ut en og en rad, og deretter for hver rad hente ut alle som har den som parent.

 

alternativet å hente ut hele røkla med en gang og sjekke når neste tråd begynner vil ikke være spesielt mye verre. jeg kan ikke si noe konkret om hastighetsproblemer, men regner med forumet skal være rimelig stort før det får noe å si.

 

Okay så min foretrukne løsning med 1 query per parent-rad vil ikke redusere ytelsen så veldig mye?

Endret 18. januar 2004 av cipher

[????????]

jeg kan ikke si noe konkret om hastighetsproblemer, men regner med forumet skal være rimelig stort før det får noe å si.

På de få linjene i eksempelet mitt ovenfor brukte LEFT JOIN under halve tiden, så det trengs ikke nødvendigvis så mye data. Nå ligger det ikke mye data i tabell 1, men det gjør det heller ikke i tabell 2, så det vil være ganske jevnt like vel regner jeg med.

 

Foreløpig er det snakk om 0.002 sek forskjeller - men gang det med flere brukere på scriptet + flere brukere på mysql databasen + eventuelle andre spørringer og server jobb dersom man kjører andre script også (spesielt ved shared hosting).

 

I rushtid, ved søkinger i databasen og mye annet, er 0,002 sek fort mye - med tankte på at dette er tiden på en lokal server hvor dette var eneste spørring.

[Torbjørn]

her ble det mye poster på en gang plutselig.

 

kanskje jeg brukte litt for "barnehage-språk" i den posten, du ser ut til å være kjent med sakens stilstand. prøv gjerne begge måter, jeg har ikke testet slik ??????? (har du et mer håndterlig navn i tillegg?) sier han gjorde. hvis du kjører mysql på samme host som web, så bør det ikke vært noe problem.

[Torbjørn]

??????: ser du har en måletid i siste desimal; 0.002 er ikke nødvendigvis dobbelt så tregt som 0.001, da du ikke kan vite om 0.002 egentlig er 0.0015 og 0.001 egentlig er 0.0014

[????????]

??????: ser du har en måletid i siste desimal; 0.002 er ikke nødvendigvis dobbelt så tregt som 0.001, da du ikke kan vite om 0.002 egentlig er 0.0015 og 0.001 egentlig er 0.0014

Kuttet ut de siste tallene for å gjøre det enklere (bruker microtime).

 

Her er resultatet fra 5 tester.

Øverste tallet er tid på LEFT JOIN

 

0.00139117240906

0.00333499908447

 

0.00137686729431

0.00305795669556

 

0.00142502784729

0.00313901901245

 

0.00139093399048

0.00302314758301

 

0.00137901306152

0.00313305854797

 

MySQL er på samme server som PHP!

 

LEFT JOIN burde i slike tilfeller være beste, men hadde vært fint om noen andre også kunne test.

 

 

EDIT

Kom i gjen Torbjørn - tror du jeg er så ny på PHP?

Endret 18. januar 2004 av ????????

[Torbjørn]

dette er ikke php, men statistikk 8)

 

interessange målinger, når du først er i gang: gidder du fylle i dummy data og se på hva dette får å si for f.eks et forum med 2000 poster

[cipher]

la oss ta et eksempel da. La oss si at vi har et forum, og på en side skal vi vise alle innlegg hvor alle svar ligger gruppert under riktig trådtittel. Hvordan ville dere løst dette?

 

+ tråd

- svar

- svar

+ tråd2

- svar 2

- svar 2

[????????]

interessange målinger, når du først er i gang: gidder du fylle i dummy data og se på hva dette får å si for f.eks et forum med 2000 poster

wow... det kan ta litt tid avhengig av hvor mange penner det skal være og hvor mange farger på hver penn.

Dersom som det er ekstremt mange farger i forhold til penner, vil nok tallet jevne seg ut og løsningen med LEFT JOIN vil nok bli den tregeste.

 

Jeg la til 10 penner, og 200 farger på hver penn - og da tapte LEFT JOIN. Men det er ikke ofte et forum har 200 svar på alle poster, så det stemmer ikke med virkligheten.

 

Oppsummeringen kan vel bli at LEFT JOIN vil være bedre så lenge det ikke er ekstremt mange svar på alle trådene, men å bruke flere spørringer kan av og til lønne seg. NB: denne testen ble utført på min lokale server, så resultatet gir bare en indikasjon.

 

Man burde hastighetsteste scriptene sine.

[Torbjørn]

cipher: de fleste forum har en "blocked" view, dvs at de viser f.eks subject, forfatter og author på trådstarter. og gjerne dato for siste inlegg. du vil ikke gå for en sånn løsning i stedet? da omgår du dessuten hele problemstillingen i tillegg til at det ofte blir penere

[cipher]

Det er godt mulig, men det var bare for å få et eksempel på problemstillingen. Jeg driver ikke å lager et forum eller noe slik. Har kommet frem noen synspunkter i tråden, men jeg sitter alikevel igjen minst like forvirret dessverre...

[Ueland]

henter ut litt ting fra 3 forskjellige tabeller (topics, posts, medlems tabell)

SELECT t.tittel, t.status, p.post, p.forfatter, b.brukernavn FROM forum_topics t, forum_posts p, forum_members b WHERE b.id = p.forfatterid AND p.topicid = t.id

 

MySQL crewet mener at LEFT JOIN er best, jeg sitter selv og utvikler et egenhendig forum men der kjører jeg stylen ovenfor enda før jeg går over alt en runde senere og stresstester etc for å finne ut hvilke spørringer som gjør jobben raskest.

[cipher]

hvordan sorterer du resultatet med PHP'en da? Jeg har også hørt at LEFT JOIN foretrekkes av mysql teamet, og jeg synes det er en mye renere syntax også. Alikevel er jeg i tvil om hvordan behandle dataen riktig hvis det er snakk om 1 til mange spørringer.

[Torbjørn]

du sorterer data som vanlig, med "ORDER BY". hvis kolonnen er definert i mer enn en tabell må du spesifisere hvor kolonnen hører hjemme, eks "ORDER BY posts.date"