Rekenen met weken
Ik vraag me af of er net als DATEDIFF ook een TIMDIFF is ? Of een manier om dit in SQL te kunnen doen
Ik probeer nu dit:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
$q = 'SELECT SUM(uur_id) as dagen,
SUM(DATEDIFF(minute,uur_start,uur_eind)) as uren,
SUM(uur_vrij) as vrij
FROM urenlijsten
ORDER BY uur_id ASC
GROUP BY EXTRACT(MONTH from uur_start)';
SUM(DATEDIFF(minute,uur_start,uur_eind)) as uren,
SUM(uur_vrij) as vrij
FROM urenlijsten
ORDER BY uur_id ASC
GROUP BY EXTRACT(MONTH from uur_start)';
Uiteraard weet ik dat dit niet zal werken, maar dan hebben jullie een idee wat ik probeer te doen.
Dit is voor het periodieke overzicht dat ik een simpel overzicht krijg van totaal aantal uren in de periode.
Waarna ik dus een link maak naar het overzicht van de urenlijsten (p week) van de periode.
Ik vroeg me dus af hoe ik in SQL de tijd tussen 2 datetimes kan opsommen.
Maar misschien makkelijker om te kijken naar TIMESTAMPDIFF (op dezelfde pagina iets naar beneden).
Nogmaals bedankt:
Code (php)
1
2
2
SELECT COUNT(uur_id) AS dagen_gewerkt, EXTRACT(YEAR FROM uur_start) as jaar, EXTRACT(
MONTH FROM uur_start ) AS maand, SUM( TIME_TO_SEC( TIMEDIFF( uur_eind, uur_start ))/60)AS minuten_gewerkt, COUNT(uur_vrij) AS uren_vrij FROM uren WHERE uur_userid = <ID> GROUP BY YEAR(uur_start), MONTH(uur_start)
MONTH FROM uur_start ) AS maand, SUM( TIME_TO_SEC( TIMEDIFF( uur_eind, uur_start ))/60)AS minuten_gewerkt, COUNT(uur_vrij) AS uren_vrij FROM uren WHERE uur_userid = <ID> GROUP BY YEAR(uur_start), MONTH(uur_start)
Gewijzigd op 19/07/2013 20:33:51 door Dennis WhoCares
Erwin H op 18/07/2013 21:28:40:
Het een beter dan het ander, nee, zoals altijd. Maar wel goed om beide standpunten te weten en te begrijpen, mag iedereen weer zijn eigen keuze maken.
Ger van Steenderen op 18/07/2013 19:38:38:
In hoeverre iets van toepassing is, is afhankelijk van de toepassing.
naar mijn idee, om het toch nog eens te zeggen, dat wanneer je een database gebruikt in het algemeen, gebruik je PHP enkel als medium om de databasegegevens aan de gebruiker te presenteren (danwel doorsturen voor bijvoorbeeld een functie etcetc), maar zeker niet wat uit de database te halen, daar eerst flink op te bewerken en dan pas 'doorsturen'
om het veel fout gebruikte voorbeeld van alles selecteren met * aan te halen: vaak wordt de hele database opgehaald, om maar 1 kolom te gebruiken. dus wat dan logisch is is die ene kolom selecteren. als je dat doortrekt, en de database al het werk laat doen, krijg je in PHP hele 'schone' data binnen, waar je gelijk iets mee kunt.
natuurlijk speelt snelheid ook een rol, ik heb niet echt een idee qua snelheden, maar een goed geoptimaliseerde database opzet en goede queries, kom je al snel tot hele efficiënte queries, waar je in PHP niks meer aan hoeft te doen.
maar wat Erwin al zei, er is geen ultieme waarheid, meer een verschil van interpretatie en voorkeuren. wees er altijd van bewust dat er een andere kant is, en dan kun je al gelang naar de situatie de beste toepassing kiezen.
Jeroen VD op 20/07/2013 15:55:59:
natuurlijk speelt snelheid ook een rol, ik heb niet echt een idee qua snelheden, maar een goed geoptimaliseerde database opzet en goede queries, kom je al snel tot hele efficiënte queries, waar je in PHP niks meer aan hoeft te doen.
natuurlijk speelt snelheid ook een rol, ik heb niet echt een idee qua snelheden, maar een goed geoptimaliseerde database opzet en goede queries, kom je al snel tot hele efficiënte queries, waar je in PHP niks meer aan hoeft te doen.
In hoeverre heeft VELE resultaten (rows) efect op deze snelheden van ophalen?
Met vele bedoel ik dat er zeer veel resultaten in de tabel staan bijvoorbeeld in 10.000 rows, waar ik misschien ... maximaal uiterlijk 366 van ophaal, waarmee dus mn bovenstaande query uiteindelijk mee wordt uitgevoerd?
Omdat ik toch in het totale overzicht per jaar maak.
(Dit is wel een extreem voorbeeld van een zeer ernstige workaholic ;-), in een schrikkeljaar)
Maar als je een hele grote dataset hebt ontkom je daar toch niet aan, je kunt dan enkel zo optimaal mogelijk maken.
Dus stel je hebt ..... WHERE user_id = 1234
Als dan de kolom user_id een index heeft dan kan die index gebruikt worden, dus als dat user_id 366 rijen in de tabel heeft hoeven alleen die 366 rijen afgelopen worden, ongeacht hoe groot die tabel is.
10.000 rijen stelt niet zoveel voor, alleen als je bv 3 tabellen gaat joinen met elk 10.000 en je hebt geen indexen op de kolommen waarop je joined dan worden het 1.000.000.000.000 rijen!
Als je twijfelt of als je query traag is zet EXPLAIN voor de oorspronkelijke query dan kan je zien wat er gebeurd.
Erwin H.:
Nou ja, ik denk dat we er van de andere kant naar kijken. Als je naast de datum ook het weeknummer opslaat dan heb je in feite dubbele informatie. Mocht je de datum dus eens moeten aanpassen, dan moet je ook het weeknummer aanpassen anders krijg je inconsistenties in je database.
Ik kijk er dus naar dat je dat wil vermijden tenzij het echt heel duidelijke voordelen heeft (die er dus wel degelijk zijn in bepaalde gevallen). Jij kijkt er zo te zien vanaf de andere kant naar, dat het beter is om het weeknummer wel op te slaan omdat je dan die mysql functies niet hoeft te gebruiken en nog wel de indexen ter beschikking hebt.
Ik kijk er dus naar dat je dat wil vermijden tenzij het echt heel duidelijke voordelen heeft (die er dus wel degelijk zijn in bepaalde gevallen). Jij kijkt er zo te zien vanaf de andere kant naar, dat het beter is om het weeknummer wel op te slaan omdat je dan die mysql functies niet hoeft te gebruiken en nog wel de indexen ter beschikking hebt.
Nee hoor ik kijk er exact hetzelfde naar, alleen wilde ik de andere kant ook eens belichten.
Ik zal eerst kijken of er goede alternatieven zijn en tot nu toe heb ik die altijd weten te vinden.
@Jeroen
Ik denk dat iedereen het er wel over eens is dat je geen gegevens uit een database moet halen, waarvan je een gedeelte niet gebruikt, je haalt alleen op wat je nodig hebt.