SQL berekenen vanaf papier

[gvh12]

Goedenavond,

Op school heb ik SQL gehad, maar hiervan is niet alles goed uitgelegd.

De SQL string is:
SELECT COUNT(*) AS aantal_1, COUNT(slber) AS aantal_2
FROM student INNER JOIN resultaat ON idcode = student;

Ik heb zelf geprobeerd uit te zoeken idcode te vergelijken met student en de primary key de dubbele eruit te halen, maar dit was niet goed.
Ik weet dat het antwoord 8 en 6 is.. maar ik weet niet hoe de berekeningen zijn gedaan om tot dat antwoord te komen.
Kunnen jullie mij misschien helpen om er enige logica achter te zoeken?

bij voorbaat dank,

 

[Tha Devil]

Zeg eerst maar tegen je docent dat dit schema nooit gebouwd kan worden

De tabel "Resultaat" heeft als PRIMARY KEY de velden "student" en "blok", wat dus inhoudt dat die combinatie uniek in de tabel moet zijn.

Dus 3x de combinatie "20122222" met "INF-A" levert een foutmelding op

Daarnaast zou ik voor de datum velden het type DATE gebruikt hebben wat de notatie zo maakt: YYYY-MM-DD in plaats van nu DD-MM-YYYY.

Verder is het een kwestie van ontleden, je begint met de INNER JOIN.

Wat die doet is het combineren van de tabel Student met Resultaat waar "Student.idcode" is gelijk aan "Resultaat.student"

Dat levert dus theoretisch deze tabel op:
[table="class: grid, align: left"]
[tr]
[td]idcode[/td]
[td]naam[/td]
[td]woonplaats[/td]
[td]leeftijd[/td]
[td]zakgeld[/td]
[td]slber[/td]
[td]student[/td]
[td]blok[/td]
[td]datum[/td]
[td]cijfer[/td]
[td]beoordelaar[/td]
[/tr]
[tr]
[td]20121234[/td]
[td]Misja[/td]
[td]Den Haag[/td]
[td]22[/td]
[td]8[/td]
[td]TC[/td]
[td]20121234[/td]
[td]INF-A[/td]
[td]21-09-2012[/td]
[td]8[/td]
[td]VB[/td]
[/tr]
[tr]
[td]20121234[/td]
[td]Misja[/td]
[td]Den Haag[/td]
[td]22[/td]
[td]8[/td]
[td]TC[/td]
[td]20121234[/td]
[td]INF-C[/td]
[td]01-10-2012[/td]
[td]8[/td]
[td]OZ[/td]
[/tr]
[tr]
[td]20122222[/td]
[td]Francien[/td]
[td]Zoetermeer[/td]
[td]18[/td]
[td](null)[/td]
[td]BD[/td]
[td]20122222[/td]
[td]INF-A[/td]
[td]21-09-2012[/td]
[td]2[/td]
[td]TC[/td]
[/tr]
[tr]
[td]20122222[/td]
[td]Francien[/td]
[td]Zoetermeer[/td]
[td]18[/td]
[td](null)[/td]
[td]BD[/td]
[td]20122222[/td]
[td]INF-A[/td]
[td]31-09-2012[/td]
[td]4[/td]
[td]VB[/td]
[/tr]
[tr]
[td]20122222[/td]
[td]Francien[/td]
[td]Zoetermeer[/td]
[td]18[/td]
[td](null)[/td]
[td]BD[/td]
[td]20122222[/td]
[td]INF-A[/td]
[td]11-10-2012[/td]
[td]6[/td]
[td]VB[/td]
[/tr]
[tr]
[td]20123333[/td]
[td]Zeyd[/td]
[td]Den Haag[/td]
[td]22[/td]
[td]8[/td]
[td](null)[/td]
[td]20123333[/td]
[td]INF-A[/td]
[td]21-09-2012[/td]
[td]8[/td]
[td]TC[/td]
[/tr]
[tr]
[td]20123333[/td]
[td]Zeyd[/td]
[td]Den Haag[/td]
[td]22[/td]
[td]8[/td]
[td](null)[/td]
[td]20123333[/td]
[td]INF-B[/td]
[td]21-09-2012[/td]
[td]10[/td]
[td](null)[/td]
[/tr]
[tr]
[td]20124444[/td]
[td]Sirish[/td]
[td]Den Haag[/td]
[td]20[/td]
[td]8[/td]
[td]TC[/td]
[td]20124444[/td]
[td]INF-B[/td]
[td]31-09-2012[/td]
[td]4[/td]
[td]VB[/td]
[/tr]
[/table]

Op die tabel wordt dan het totale aantal rijen (COUNT(*)) opgevraagd en het totaal aantal slbers (COUNT(slber)), omdat NULL geen waarde is wordt die niet meegerekend.

 

[PgVincent]

De tabel "Resultaat" heeft als PRIMARY KEY de velden "student" en "blok", wat dus inhoudt dat die combinatie uniek in de tabel moet zijn.

Als de underscore betekent dat het een PK is wel, maar als het betekent dat het "een key" is, dan is er niets aan de hand, en ik gok op het tweede

Daarnaast zou ik voor de datum velden het type DATE gebruikt hebben wat de notatie zo maakt: YYYY-MM-DD in plaats van nu DD-MM-YYYY.

DATE heeft geen notatie, hoe de inhoud wordt getoond en geinterpreteerd hangt af van de locale instellingen en die kunnen ook dd-mm-yyyy geldig maken.

 

[Tha Devil]

Is de standaard notatie van DATE niet YYYY-MM-DD?

The DATE type is used for values with a date part but no time part. MySQL retrieves and displays DATE values in 'YYYY-MM-DD' format. The supported range is '1000-01-01' to '9999-12-31'.

http://dev.mysql.com/doc/refman/5.5/en/datetime.html

Hoe je het er vervolgens uit haalt kun je zelf bepalen aan de hand van DATE_FORMAT voor zover ik weet, maar je zult het er altijd in moeten stoppen als YYYY-MM-DD.

Mijn aanname is dat dit gewoon een letterlijke dump van de tabel is (En dat kolommen die onderstreept zijn als PK fungeren )

 

[PgVincent]

Is de standaard notatie van DATE niet YYYY-MM-DD?

Klopt, maar dat is dus alleen maar de standaard instelling. Bijvoorbeeld, bij PostgreSQL kun je te allen tijde de "datestyle" setting instellen op wat jouw applicatie nodig heeft, en dan kun je dus ook dd-mm-yyyy opgeven en vervolgens al je datums als dd-mm-yyyy van de database krijgen en ook als dd-mm-yyyy aan de database voeren (dan hoef je dus niets om te zetten naar yyyy-mm-dd). DATE zit wat dat betreft dus niet vast aan yyyy-mm-dd tenzij de standaard instelling yyyy-mm-dd is en je die niet verandert.

Mijn aanname is dat dit gewoon een letterlijke dump van de tabel is

Logisch, maar ook daar is de date geformateerd volgens de locale van de tool die de dump maakte en dus kan het prima een DATE veld zijn dat door een Nederlandse Locale wordt uitgelezen en dus dd-mm-yyyy gebruikt.
(meer waarschijnlijk is dat deze dump gemaakt is door een leraar, met MS-Access... of Excel... brrrr...)