SQL hämta tidigaste starttiden

Har kört fast på en skoluppgift och vi har ingen handledning närmsta veckorna eller möjlighet att mejla läraren.

Har en tabell med tävlingar, med primary key starttid.
Behöver få ut ett namn på den person som senast tävlade. Enda tipset vi fått är använd curdate.

har försökt med följande:

select Ryttare.namn, curdate(starttid)
from Ryttare, Tävling
where Ryttare.pnr=Tävling.pnr
group by Tävling.starttid;

Googla på "order by"

SELECT TOP 1 Ryttare.namn, Tavling.starttid
FROM Ryttare, Tavling
WHERE Ryttare.pnr = Tavling.pnr
ORDER BY Tavling.starttid DESC, Ryttare.namn

Nu är jag grymt sen på bollen och Smurfanerlite har gett dig ett giltigt svar. Däremot så vill jag tipsa om att använda lite mer modern SQL-syntax, som faktiskt är tydligare i vad du vill göra och varför:

SELECT TOP 1 r.namn, t.starttid
FROM Ryttare r
INNER JOIN Tavling t ON r.pnr = t.pnr
ORDER BY t.starttid DESC;

Dels använder jag mig av tabell-alias. Istället för att på varje ställe det används, skriva ut tabellnamnet, så skriver man bara aliaset. Mycket smidigare och i de fall man behöver använda tabellen mer än en gång i samma fråga, är det nödvändigt att använda sig av alias.

Om man "joinar ihop" två eller fler tabeller, ska aliaset användas överallt där kolumnnamn spec:as. Då slipper man en massa funderingar i efterhand om var datat kommer ifrån. Använder man sig av endast en tabell är alias onödigt.

Själva joinen då? Det finns en massa olika sätt att koppla ihop tabeller och därför är det bättre att lära sig rätt syntax från början.

Sedan funderade jag ett varv till och varför skulle du använda dig av curdate, som ger dig dagens datum? Enda tanken som poppar upp, är att tabellen Tavling innehåller kommande tävlingar och för att se vem som tävlade sist, till skillnad från vem som kommer tävla sist, måste frågan se lite annorlunda ut:

SELECT TOP 1 r.namn, t.starttid
FROM Ryttare r
INNER JOIN Tavling t ON r.pnr = t.pnr
WHERE t.starttid < CURDATE()
ORDER BY t.starttid DESC;

Om det är så att starttid är datum och tid, så bör man använda sig av CURRENT_TIMESTAMP() istället för CURDATE() som bara jämför datum. Blir lite olika resultat om man använder fel nämligen.

Det var ett rätt bra svar. Jag är pensionär, men programmerar så att säga för eget bruk.

Sql är ett skitspråk. Många fattar inte vad det är för tokerier de skriver, de är nöjda med rätt resultat.

Använder man inner join, kan den vänstra och den högra tabellen sorteras på de kolumner man vill joina på.
Ni kan ju roa er med att rita upp två tabeller på papper och flytta två pennor mellan de två tabellerna, såsom ni tycker är mest lämpligt när tabellerna är sorterade på kolumnerna det skall joinas på.

Skriver man vad man vill uppnå med en join efter where, så blir det 'cartesian product' och därefter en selektion.

Om vi nu antar att den vänstra tabellen innehåller 1 000 rader och den högra 10 000 rader. 1 000 * 10 000 rader blir rätt många rader och den virtuella tabell som är resultatet av det skall det göras en selektion av. Det blir rätt mycket data. Tur att inte hålkort används längre typ... Då hade det behövs illeverans från pappersbruket.

...och när man väl tror sig få rätt resultat är det ingen som varken kan, vill eller orkar ifrågasätta resultatet. Jag som snart blir pensionär fick ta över ett bautaprojekt (c#, .net och mssql uppe i fluffet) som ingen orkat med (annat än panikfixat) sedan det sjösattes för över 10 år sedan - har inte gjort annat än squishat buggar de senaste tre åren. Systemet används av ett top10 företag i sverige plus ett par till.

Tvärtom. SQL är ett kompetent språk, anpassat till att hantera data.

Det är som vilket verktyg som helst. En hammare är bra att slå in spik med, med rätt uselt för att såga ner ett träd med. Sedan är det med SQL, precis som med alla andra verktyg, har du utbildning och erfarenhet, blir resultatet mycket bättre.

Om man skriver att SQL är ett skitspråk vet man inte vad det handlar om.

Det är ett frågespråk, inget annat. Det som avgör om din fråga får ett svar mer eller mindre effektivt har två sidor, dels bör ju din fråga vara skriven på rätt sätt, och om du skriver skit blir det skit, och dels, och nu kommer vi till den viktigaste delen, så behöver du rätt underliggande fysiska strukturer, index, partitionering med mera.

Ber moderatorn om ursäkt i förväg, men nu bär det iväg off topic.

För att en databaslösning ska vara effektiv, så måste du göra saker i rätt ordning (det finns också ett visst mått av pedagogik i att göra som nedan):

1. Rätt datamodell
Tredje normalformen i all sin ära, men ännu bättre är att våga göra avsteg från reglerna när det behövs och ha en datamodell som stödjer hur datat faktiskt används. Har man vald fel datamodell, jobbar man i uppförsbacke resten av tiden, för det är långt ifrån enkelt att börja rodda om i modellen, när allt är uppe och snurrar i produktionsmiljön.

2. Ställ frågan rätt
Som vi har varit inne på i den här tråden, finns det flera sätt att få svar från databasen. I verkligheten försöker man hitta det där optimala sättet att ställa frågan på rätt sätt. Vad rätt sätt är, beror helt och hållet på situationen. Spelar kanske ingen roll på hobbydatabasen ingen annan är inne i, men när man har tusentals frågor varje sekund mot databasen, då är det avgörande om man gör på rätt sätt eller inte.

3. Sedan kan man börja fundera på index, partitionering, cachning och liknande.
Index är ingen ensidig frälsning. Det kommer med en kostnad på skrivsidan, på lagringssidan och på underhållssidan (index måste underhållas). Samma sak med partitionering. Det kan till och med göra saker värre om man gör på fel sätt.

4. Fysiska strukturer
Sist i prioriteringen kommer hårdvaran. Den kostar pengar, så rent ekonomiskt ska man göra allt man kan hantverksmässigt, innan man börjar slänga pengar på problemet. Men visst, har man gott om pengar och kan slänga in feta servrar, hög bandbredd, snabba diskar så kan man snabbt och enkelt dölja misstagen i de tre första punkterna.

Läs det här så kanske poletten trillar ner.
https://en.wikipedia.org/wiki/Relational_algebra

Sql blev av någon obegriplig anledning standard omkring 1986. Dessförinnan fanns det ungefär lika många olika programspråk för relationsdatabaser som företag som sålde sådan programvara.

Sql underlättar inte precis för det program som tolkar sql-koden att utföra det hela så effektivt som möjligt.
Till råga på allt elände krävs det att programmeraren skriver onödigt mycket kod för att uppnå vad hen vill.
Och som jag skrev tidigare använder många fel syntax i samband med join. Det blir ju rätt resultat? Men, mycket resurskrävande, om inte databas-programvarans optimerare klarar av att ändra till något mer lämpligt.
Syntaxen är helt enkelt knäpp. Men, det är som sagt standard.

Man skulle ha väntat längre med att införa någon sorts standard!

Jag glömde bort att skriva att det var mycket bra att påpeka att inner join skall användas istället för join med komma-tecken, om det är inner join man vill uppnå.
Det var exakt det jag försökte förklara i mitt första inlägg.
Läs och tänk efter och hoppas på att något annat språk blir standard.
Tyvärr kommer nog inte detta att hända.

Hur länge ska man vänta på att införa en standard? Tills ingen använder det längre, så man med facit i hand kan utröna vad som var bäst? Varför finns det så många olika programmeringsspråk? De flesta är rätt lika varandra ändå, eller hur?

När det gäller SQL, så är det faktiskt lätt för databasmotorn att tolka koden man skriver, vad utvecklaren vill åstadkomma. Problemet uppstår när man blandar in datat. Hur hämtar man önskat data på effektivast sätt? Det är ju där index, partitioneringar, query plans, statistik och sånt kommer in och det är där det blir rätt invecklat rätt fort.

Är SQL det mest effektiva sättet att skriva kod, så att en databasmotor kan förstå vad du vill? Jag har svårt att se ett mer kompakt sätt att skriva datahanteringskod. För det är ju det databasen ska göra, hantera data i stora mängder. Problemet uppstår snarare när utvecklaren försöker använda SQL till något slags presentationsverktyg, då är det lätt att det blir mycket kod och rörigt.

Har du något förslag till hur datahanteringskod skulle skrivas mer effektivt?

Vad gäller syntaxen så anser jag att den är glasklar och de olika delarna är tydligt avskilda och i vilken ordning databasmotorn måste hantera dom. Vilka tabeller ska användas och hur ska de kopplas ihop (FROM/JOIN). Vad ska filtreras bort/fram (WHERE). Ska resultatet grupperas (GROUP BY) och det resultatet i sin tur filtreras (HAVING). Sen kommer sorteringen (ORDER BY) och antalet rader som ska visas (LIMIT). Sist kommer det man skriver först, nämligen vilka kolumner från tabellerna i fråga som är intressanta (SELECT).

Microsoft har fått vissa saker om bakfoten och lagt in sin LIMIT i SELECT-delen (som TOP), vilket jag anser bryter mot hela tänket. Där håller jag med om att syntaxen är knäpp.