Først av alt: Jeg vet jeg burde gå over til mysqli eller lignende, men det kommer i neste versjon av siden.

Jeg har en spørring som fungerer i phpMyAdmin, men når jeg tar den over i php-koden så fungerer den ikke:

$Qlagrank="
SET @lagid_rank = '0';
SET @current_lagid = '0';
SELECT lagnavn, SUM(ncfpoeng) as lagpoeng, lagid, lagtypeid
FROM
(SELECT lagsesong.lagnavn, rytterlagsesong.lagid, rytterlagsesong.ncfpoeng, lag.lagtypeid,
@lagid_rank := IF(@current_lagid = rytterlagsesong.lagid, @lagid_rank + 1, 1) AS lagid_rank,
@current_lagid := rytterlagsesong.lagid
FROM rytterlagsesong
JOIN lagsesong ON lagsesong.lagid=rytterlagsesong.lagid AND lagsesong.sesong=rytterlagsesong.sesong
JOIN lag ON lagsesong.lagid=lag.lagid
WHERE rytterlagsesong.klasse='MSenior' AND rytterlagsesong.sesong='2015' AND rytterlagsesong.ncfpoeng>='1'
ORDER BY lagid, ncfpoeng DESC
) ranked
WHERE lagid_rank <= '3'
GROUP BY lagid
ORDER BY lagpoeng DESC";


$Lagrank=mysql_query($Qlagrank);
var_dump($Lagrank);

var_dump returnerer bool(false)

Det spørringen skal gjøre er å gi meg de tre beste på hvert lag i en klasse og regne ut totalpoengsummen deres. Hvis jeg tar bort de to SET så summerer den alle på laget og ikke de tre beste.

Håper noen kan hjelpe meg!

En god approach for å få hjelpe er å prøve å forklare bedre hva slaks problem du prøver å løse - fremfor å fortelle hvordan du har prøvd å løse det. For det kan godt være det finnes løsninger som er helt annerledes enn hva du har tenkt. Og det kan f.eks. være det finnes betydelig lettere måter å skrive den spørringen på.

Hvordan ser tabellene ut? Og hva mener du med å regne ut poeng? (hva er poeng i denne sammenhengen?)

Håpte vel at det bare var en enkel feil rundt bruk av SET som var lett for ett trent øye å gi meg svar på!

Men her kommer en mer detaljert forklaring.

SYKL er en statistikkside for norske landeveisritt (sykkel).
Det jeg ønsker er å regne ut poengsummen til de tre beste på hvert lag fra en tabell som hetter ryttersesong:
der finnes lagid, og ncftotalt (som er rytterens totalsum).

Jeg vil altså ha en spørring som henter ut de tre med høyest ncftotalt for hver lagid, og summere den for hver lagid.

(Så må jeg og luke ut slik at det er rytterne i rett klasse og rett sesong som regnes ut, samt hente lagnavn fra en annen tabell, men de tingene skal jo ikke påvirke utregningen)

Løsningen min er hente fra denne artikkelen: http://www.sqlines.com/mysql/how-to/...p_n_each_group
Men jeg fikk den først til å fungere i phpMyAdmin når jeg satt en verdi til de to variablene først.
Når jeg klipper den ut fra phpMyAdmin og inn i php-koden min, da fungerer den ikke lengre.

Håper dette oppklarte litt mer. Hvis ikke håper jeg dere spør for å oppklare mer.

TABELL FORENKLET

rytterid | lagdid | sesong | ncftotalt | klasse
--------------------------------------------------
42 | 1 | 2015 | 2345 | MSenior
24 | 1 | 2015 | 1203 | MSenior
32 | 2 | 2015 | 1025 | MSenior
68 | 1 | 2015 | 7654 | MSenior
54 | 2 | 2015 | 4321 | MSenior
62 | 1 | 2015 | 2004 | MSenior
14 | 2 | 2015 | 1305 | MSenior

Hva prøver du å gjøre? Hvor mange tabeller har du? Hvordan ser tabellen(e) ut? Tegn dem opp, ettersom formateringen ikke blir rett hvis du bare limer inn.

Kjedet meg, så bestemte å prøve å lage ett skript til deg, du sa ikke mysqli, så jeg brukte vanlig mysql. Tar forbehold om skrivefeil, ettersom det er en stund siden jeg har skrevet mysql-spørringer manuelt. Hele greia er utestet, og den er også usikker, så jeg vil anbefale deg å skrive din egen versjon, denne er kun ett forslag.

Denne tar utgangspunkt i at du vil summere ncftotalt for ALLE på ett lag, og ikke bare de tre toppspillerne.

Og jeg dreit også i komplisert mysql, har aldri likt det.

Ang å drite i avansert SQL: SQL skalerer ofte mye bedre enn ting som PHP, så man får ofte store ytelsesforbedringer ved å la databasen få litt ansvar for å behandle dataen. (Men selvfølgelig, finnes spørringer som kan finne på å kvele hele databasen og)

etse: Joda, det er sant, og jeg vet at jeg sannsynligvis blir nødt å lære meg det ordentlig hvis jeg noengang går pro, men enn så lenge koder jeg bare som ett hobbyprosjekt så er ikke vitalt.

Det er som oftest der man har glemt å lage nøkler.

Takk for alle svar!

-Jeg bruker php 5.6

-Vet ikke om det er så mye mer å si om tabellen, det er jo kun lagid og ncftotalt som bør være relevante (eventuelt sesong og klasse)

- Det jeg ønsker er å summere ncftotalt for de tre beste på hvert lag, og på den måten lag en "lagtabell"

- Jeg prøvde å fjerne SET, men da gir det meg totalsummen for hvert lag, og ikke for de tre beste. sprinft() forstod jeg ikke helt hvordan jeg skulle bruke...

For all del IKKE finn på å bruke det klassiske mysql grensesnittet til PHP. Det har status som deprecated lenge nå, og det er flere gode grunner til det.
Lær deg PDO først som sist, og du vil takke deg selv senere.

Det å gå fra MySQL til MariaDB er minimalt med arbeid når man skal konvertere, alle query's og all kode vil fortsatt funke den dagen de bestemmer seg for å legge ned MySQL. Når Orginal MySQL API til php blir tatt ut av pakken vil alt dø og det hardt, mye kode må skrives om osv. Enten bør det skrives med PDO eller mysqli

Jo, så klart, men "ingen" klarte å gjøre dette riktig. Det var en grunn til at PHP hadde ett rykte på å være usikkert for noen år tilbake.

Ett annet stort pluss er jo også at PDO er objekt orientert, kontra klassisk php_mysql

Holy shit, wtf?!?

1. Grunnen til å bruke PDO er at det er best practice, "garantert" sikker parameterisering er en stor grunn til dette. Det er uansett en jævla dårlig idé å bruke hjemmesnekra sikkerhetsløsninger, enten det er snakk om parameterisering av spørringer eller andre ting som tross alt er ganske kritisk.
   
   PHP er allerede nok av en vits om du ikke i tillegg skal droppe store deler av funksjonene det gir deg gratis fordi de "fint kan lages selv med array og noen ifer" - et sitat som forøvrig kvalifiserer til Darwin Awards i software design. Du har ikke lyst på SQL-injections fordi du glemte en eller annen special case.
   
   
2. Wat. Jeg skjønner ikke engang sammenhengen i denne påstanden, men nei, native er ikke alltid best, hva nå enn det er du sikter til med hensyn til både "nativeness" og kontekst.
   
   
3. CouchDB og MariaDB er sikkert brukende til noe, men hvorfor bruke dette i stedet for velkjente, veletablerte, veldokumenterte relasjonelle databaser?
   
   
4. Det eneste fornuftige jeg noen gang har sett deg skrive på dette forumet - gratulerer!
   
   
5. MySQL er ikke deprecated, og viser heller ikke tegn til å bli det i noen som helst slags nær framtid.

Godt sagt. Det eneste jeg har å pirke på: MariaDB er en velkjent, veletablert, veldokumentert database. Det er en fork av MySQL ledet av de originale MySQL-utviklerne, og bl.a. Google har gått fra MySQL til MariaDB.

En vanlig feil er å bruke NoSQL (som f.eks. CouchDB) bare fordi det er kult og hipt, når man egentlig har relasjonelle data, som OP tydeligvis har.

PDO er kanskje best practice, men det er ihvertfall ikke the road the less travelled.

Rammeverk som snakker native er alltid bedre enn rammeverk som går gjennom flere ledd for å nå native nivå. ... og det kan fort bli litt som Kamelåså!

For meg er NodeJS/pg-native/postgreSQL førstevalget, men couchDB har langt bedre ytelse og dersom ytelse er et krav er CouchDB vesentlig bedre enn alternativene jeg kjenner til. F eks telekom logger over samtaler og tekstmeldinger, klarer ikke postgreSQL å svelge unna, men couchDB tar dette helt fint, kan da kjøre spørringer fra postgreSQL gjennom FDW.

Har det faktisk skjedd noe med MySQL siden 2005? Jeg vet det plutselig kom støtte for XML import, men utenom det?

Nei, det kjem jo an på kva rammeverket faktisk gjer, og kva det gir deg. Tek du med velikehald av ditt heimesnekra rammeverk, tid til utvikling, features etc. så vil det gje heilt anna bilete.
What?

CouchDB er ikkje ein relasjonsdatabase. OP har relasjonsdata. Telecomlogger er og godt døme på relasjonsdata. CouchDB lagrer enkeltartikler, ikkje relasjonsdata. Å foreslå det er skivebom.

Eg kjøper heller ikkje ytelsespåstanden din, all den tid det å samanlikne epler og pærer er vanskeleg; sjølvsagt er det raskare å lagre unna data utan relasjoner, enn eit komplekst relasjonsopplegg med indekser og shit. Så du kan sjølvsagt underbygge påstanden din om ytelse?
https://dev.mysql.com/doc/relnotes/m...ws-5-6-26.html
Pluss en haug liknande changelogs. Og kva forventer du av endringer, om du skal ha ein database som støtter det samme? Har du i heile teke peiling på kva du snakker om?

Trykket på kp ved en feil.

Alle native funksjonalitet i PHP er skrevet i C++, og blir kompilert til native kode. Så det er ikke mye overhead på å bruke PDO, noe det vil bli ved å lage en egen spaghetti wrapper selv

PDO er noe av det beste som har skjedd PHP, og bør brukes (ingen gode unnskyldninger for å ikke bruke PDO!).

Enkelt og greit, om du må bruke PHP i prosjektet ditt, og du har en Database inn i løsningen, bruk PDO

Med opcode cache så vil jeg gjerne se grafer som viser nevnverdige forskjeller. Siden php56 har det vært skrudd på som standard med zend opcache, i eldre versjon har xcache, apc og eaccelerator vært populære valg med sine fordeler og ulemper.

Realiteten er at du med stor sannsynlighet vil bruke mer tid i databasen enn du vil på programkoden. Det er også mange oppgaver man typisk gjør i databasen som kan løses langt bedre enten i programkoden eller på klientsiden, som sortering og filtrering. Men det er også helt fjollete å optimalisere sånt før det blir et problem.

Det er absolutt ingen med et snev av fornuft som bruker noe annet enn PDO i dag, det gir deg et abstraksjonslag du vil ha, så du kan f.eks. bytte ut MySQL når Oracle ikke oppfører seg. Dessuten, når vi snakker om web applikasjoner så har vi mange verktøy for å gjøre ting kjapt, som reverse caching, ESI og key value stores for å ikke bruke databasen mer enn vi trenger. Cache is KING!