avancerad SQL-sats

Vill du göra det med SQL:en?

Eller med PHP el motsvarande?

I mysql ser det ut något i stil med:

SELECT CASE 
WHEN hemma_mal > borta_mal THEN 2 WHEN hemma_mal = borta_mal THEN 1 ELSE 0 
END 
FROM [resultat_tabell] 
WHERE match-id = [ett eller annat];

Har inte testat om det här fungerar men skulle tro det. Annars får någon annan flika in

Varför skulle man inte kunna sortera efter hur många poäng laget har fått, om man har fler än två lag?

Har svårt att förstå vad du vill ha - är det något i stil med detta:

SELECT [lagnamn/id] ,
CASE WHEN hemma_mal > borta_mal THEN 2 
WHEN hemma_mal = borta_mal 
THEN 1 
ELSE 0 
END 
AS poang
FROM [tabellen] ORDER BY poang DESC

Det här bör fungera:

SELECT lag_id, sum(poang) AS poang FROM
  (SELECT hemma_lag AS lag_id,
                (CASE WHEN hemma_mal > borta_mal THEN 2
                      WHEN hemma_mal = borta_mal THEN 1
                      ELSE 0
                 END) AS poang
   FROM matcher
   UNION ALL
   SELECT borta_lag AS lag_id,
                (CASE WHEN borta_mal > hemma_mal THEN 2
                      WHEN borta_mal = hemma_mal THEN 1
                      ELSE 0
                 END) AS poang
   FROM matcher) AS lag_poang
GROUP BY lag_id
ORDER BY sum(poang) DESC;

Nu har jag iofs inte tagit mig tid att kolla upp vilka roligheter mysql kan tänkas åstadkomma med SQL-satsen ovan, men de flesta något så när SQL92-kompatibla databashanterare ska klara det bara fint.

från och med vilken version av mysql är det man kan göra subselects?

4.1?

(Sök och du skall finna...)

MySQL Manual | 1.7.4.1 Subqueries

MySQL Manual | 1.5.2.1 Features Available in MySQL 4.1

Stämmer bra, men 4.1 är inte släppt ännu, så vitt jag vet. Bara som beta. Dessutom tror jag det var en del tråkiga begränsningar i 4.1 som inte kommer vara fixade förräns i senare releaser, tyvärr. Men det mesta som går att göra med subselects går att göra (krångligare) med JOINS.

Kommer subselect-begränsningarna alltså fortfarande att ligga kvar även i 4.1? Jag fick intrycket när jag skumläste igenom listan över sådant som skulle fixas från 4.0 att det skulle lösas i 4.1 (som iofs knappt ens var i alfaversion då). Men mysql är ju rätt bra på vaporware i övrigt också, såg för ett tag sedan att de stolt utannonserade att vyer skulle komma i version 6.0. Heja...

Men det är ju oftast som du säger, att mycket av det man löser med subselects kan göras med join-satser (som iofs då kan bli rätt otäcka historier). Däremot tror jag inte att det går att göra med exemplet här ovan, eftersom det är en nästlad union-sats. Eller?

Du kanske har flera fält i tabellen än du redovisade här, men skulle inte "omgång" vara bra att ha med. Dvs, så att man ser till vilken omgång ett resultat hör?

Sedan, trots att jag inte betvivlar att det går att konstruera hur håriga select-satser i SQL som helst, vad är poängen..? Om det är statistiskt material du skall ta fram tycker jag du bör iterera fram det i ditt favoritprogrammeringsspråk. Låt säga att det är PHP, du skall använda för att implementera affärslogiken (och presentationen) i. Det blir fantastiskt mycket mera lättbegripligt, och lättare att underhålla då.

Sedan, min lilla käpphäst... Jag tycker att tabeller, fält och variabler och kommentarer skall vara på engelska. Sorry, men det är mitt privata lilla korståg.

Bortsett från prestanda (som knappast kan sägas vara en viktig fråga i den här sortens applikation) finns det egentligen inte så stora fördelar med att lägga in über-håriga sql-satser i koden. Den sortens lösningar urartar ganska lätt till spaghettikod.

Om man däremot har en lite bättre databashanterare med stöd för vyer tycker jag att det finns en del rätt stora fördelar. Vill man, säg, ha en lista med de tre bästa lagen kan man skapa en vy ("virtuell tabell" som skapas dynamiskt utifrån en sql-sats) som sköter den biten. Då behöver man bara använda den håriga SQL-satsen en enda gång, d.v.s. när man skapar vyn, och sedan kommer man åt den med en trivial "SELECT * FROM..."-sats. Då håller man koden ren från både gigantiska SQL-satser och överflödiga iterationslösningar. Det förutsätter ju iofs att man lärt sig en del SQL, men det är en ansträngning som jag tycker är klart värd att göra

Som jag förstått det skall det lanseras på bred front i o m 4.1, men jag har för mig att det även var en del viktiga delar av subselectdelen som inte skulle komma förräns senare, och med tanke på hur länge mysql-versionerna är alfa så lär det ju dröja. Men jag kan mixat ihop det med fulltextsökningarna eller nåt.

I övrigt älskar jag manualen till mysql, och sitter och är glad över att indexeringen av några kolumner i min mastodontdatabas jag arbetar med f n gjorde att en tokfet join-union över bl a en tabell med över 10.000 poster sjönk i tid från ca 6,5 min till under 10 sekunder!

Inte för att den någonsin skall användas på det sättet, men man måste ju testa i benchmarkingsyfte, eller hur?

Samma här, försöker hålla mig till svenska men en del variabelnamn låter så fåniga att det ofta blir svengelska...

Nu tycker jag visserligen att det är bättre med en tabell där poäng, mål mm är summerade men om du inte tycker den är ordentlig så föreslår jag följande:

Istället för att krångla till det med en SQL-sats som ändå kanske är mer än mySQL klarar så gör följande: Läs upp alla poster från databasen till php, loopa igenom värdena och summera per lag i en ny array.
Använd en array med nycklar där lag_id är nyckel.
Därefter sorterar du den array:en med usort och en egen definierad sorteringsfunktion.

Joakim

En annan sak som är bra med en iterativ lösning i ditt programmeringsspråk är att du kan hantera Walk-Over och andra specialfall. Min erfarenhet av korpspel i innebandy är att det dessvärre blir nån WO-match per säsong. Det kan bli ännu omöjligare att hantera med en hårig SQL-sats än med PHP. Till sist måste jag också varna för den tickande prestandabomb som finns med komplicerade SQL-satser. Det är mycket svårt för en icke-häxmästare att se på en SQL-sats hurvida den tar exponitiellt tid i förhållande till antalet poster. En iteration över posterna i ett programmeringsspråk kan enkelt fås att utföras med linjärt förhållande mellan tidsåtgång och antal poster.

... och stickspåret med engelska eller svenska i programering.

Jag tycker inte det är "kaxigt" eller störigt att använda engelska i all kod jag skapar. Inte ens i sådan kod jag skriver för min egen del. För det första så tycker jag det blir mycket konstigt när kontrollstrukturer och själva programmeringsspråket är på engelska och resten är på svenska. Det blir dessutom totalkollrigt när man inte kan använda ÅÄÖ. Men, det största skälet för min del är att man aldrig vet när någon annan skulle vilja titta på ens kod. Ibland när jag söker på webben efter relevant kod så hittar jag något. Det kanske är nån som har gjort en egen idrottstabellslösning i MySQL och PHP som jag skulle vilja bygga vidare på... Så, visar det sig att variabelnamn och tabeller är skrivna på slovenska. Nästan omöjligt för mig att jobba vidare.