Jeg har tilføjet et svar til det foregående spørgsmål. Se venligst først til det, for at forstå det.
Du kan ikke få det fra bb_ratings
alene ved at gruppere det og hacke det. Du får Null, fordi du tænker i et gitter, ikke i relationelle sæt (det er det centrale koncept i den relationelle model).
-
Før du beslutter dig for, hvilken eller hvilke tabeller du skal gå til for at servicere din forespørgsel, skal du beslutte, hvad du vil have for strukturen af dit resultatsæt.
-
Begræns det derefter (hvilke rækker) med
WHERE
klausul. -
Find derefter ud af, hvor (hvilke tabeller) du skal hente kolonnerne fra. Enten slutter sig til flere tabeller, og mere arbejde på
WHERE
klausul; eller skalære underforespørgsler, korreleret til den ydre forespørgsel.
Du er ikke klar over, hvad du vil. Det ser ud til, at du vil have den samme rapport som det foregående spørgsmål, plus en kolonne for den givne brugers stemme. For mig er strukturen af dit resultatsæt en liste over bulletiner. Nå, det kan jeg få fra bulletin
, ingen grund til at gå til bulletin_like
og så skal du gruppere det.
Hvis du tænker i sæt, er det meget nemt, ingen grund til at springe gennem bøjler med materialiserede visninger eller "indlejrede" forespørgsler:
SELECT name AS bulletin,
(SELECT COUNT(like)
FROM bulletin_like bl
WHERE bl.bulletin_id = b.bulletin_id
AND like = 1
) AS like,
(SELECT COUNT(like)
FROM bulletin_like bl
WHERE bl.bulletin_id = b.bulletin_id
AND like = 0
) AS dislike,
(SELECT COUNT(like)
FROM bulletin_like bl
WHERE bl.bulletin_id = b.bulletin_id
AND bl.user_id = {$user_d}
AND like = 1
) AS your_vote
FROM bulletin b
Svar på kommentarer
Jeg har på fornemmelsen, at det, du siger, er meget vigtigt for, hvordan jeg griber SQL an
-
Ja absolut. Hvis du er villig til at lære de rigtige ting på forhånd, vil det:
- sparer dig alle slags problemer senere
- gør dine forespørgsler mere effektive
- giver dig mulighed for at kode hurtigere
.
-
For nu, glem alt om at bruge resultatsæt som tabeller (meget langsommere) og midlertidige tabeller (bestemt ikke påkrævet, hvis din database er normaliseret). Du er meget bedre at forespørge tabellerne direkte. Du skal lære forskellige fag såsom Relationsmodellen; hvordan man bruger SQL; hvordan ikke at bruge SQL for at undgå problemer; osv. Jeg er villig til at hjælpe dig og blive hos dig et stykke tid, men jeg har brug for at vide, at du er villig. Det vil tage lidt frem og tilbage. Der er en smule støj på denne side, så jeg vil ignorere andre kommentarer (indtil slutningen) og kun svare på dine.
- stop med at bruge
GROUP BY
, hæmmer det alvorligt din forståelse af SQL. Hvis du ikke kan få den rapport, du ønsker, uden at brugeGROUP BY
, stil et spørgsmål.
.
- stop med at bruge
-
Dette stillede spørgsmål. Fortæl mig, på hvilket tidspunkt du gik vild, og jeg vil give flere detaljer fra det tidspunkt og frem.
- For dette spørgsmål vil du have en liste over bulletiner med likes; kan ikke lide; og dette brugere kan lide. Er det korrekt ? Har du prøvet den kode, jeg angav?
.
- For dette spørgsmål vil du have en liste over bulletiner med likes; kan ikke lide; og dette brugere kan lide. Er det korrekt ? Har du prøvet den kode, jeg angav?
- Så på det linkede spørgsmål. Det er noget rod, og ingen har adresseret det dybere problem; de har besvaret problemet på overfladen, isoleret. Du har nu et svar, men du forstår det ikke. Det er en meget langsom måde at komme videre på.