sql >> Database teknologi >  >> RDS >> Mysql

Mysql Nested Select

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).

  1. 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.

  2. Begræns det derefter (hvilke rækker) med WHERE klausul.

  3. 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

  1. 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
      .
  2. 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 bruge GROUP BY , stil et spørgsmål.
      .
  3. 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?
      .
  4. 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å.


  1. solplet solr udefineret felttype

  2. Laravel-migrerings primær (eller nøgle) Identifikatornavn er for langt

  3. JPA indsæt forældre/barn resultater i MySQLIintegrityConstraintViolationException

  4. Hvordan fungerer MySQL's ORDER BY RAND()?