Online gebruikers laten zien.
Elke keer als de bezoeker een activiteit doet, word de tijd en het activiteit dat de gebruiker heeft gedaan opgeslagen als LASTACTIVITYTIME en LASTACTIVITY.
Op deze manier laat ik de recente activeit van een gebruiker zien op de profile pagina.
Nu wil ik op deze pagina ook aangeven of de gebruiker online of offline is.
Ik vroeg me af hoe dit mogelijk is?
Ik had zelf in gedachten om LASTACTIVITYTIME te vergelijken met de huidige tijd, en als daar een verschil van 15 minuten in zit, dan is de persoon niet online.
Alleen is de tijd opgeslagen als bijvoorbeeld: 22/03/2018 16:42:43
IS het mogelijk om uit bovenstaand alleen 16:42 te vergelijken of zal ik een andere field aan moeten maken wat 16:42 aangeeft?
Misschien kan iemand mij een betere manier aanraden om online gebruikers te laten zien of een voorbeeld/richtlijn hoe ik bovenstaand mogelijk maak?
Ben van Velzen op 22/03/2018 16:50:49:
Waarom is het dan niet opgeslagen als DATETIME?
Wat heeft de benaming van een veld hier nou weer mee te maken?
Hij heeft het niet over de benaming van het veld, maar over het datatype.
https://dev.mysql.com/doc/refman/5.7/en/datetime.html
In wezen zijn er twee sorteermanieren: lexicografisch (alfabetisch) of numeriek. Afhankelijk van hoe je data opslaat (als text of als cijfers) kan een sorteeropdracht verschillende resultaten hebben.
Stel dat je de data 12, 206 en 84 hebt. Als je deze opslaat als tekst, en vervolgens aflopend sorteert, dan levert je dat achtereenvolgens 84, 206 en 12 op, omdat er alfabetisch wordt gesorteerd. Sla je deze data in een nummerformaat op dan rolt hier respectievelijk 206, 84 en 12 uit, zoals je misschien zou verwachten. De KEUZE voor opslag in een bepaald formaat heeft dus GROTE GEVOLGEN voor hoe je die data vervolgens kunt gebruiken.
DATETIMEs zijn strings, maar vanwege de formattering van deze string (YYYY-MM-DD HH:II:SS) lopen de lexicografische en numerieke sortering in de pas omdat de grootste tijdseenheid (het jaar) voorop staat, dan de maand, de dag et cetera. Dit is handig omdat de sortering dan verloopt zoals je zou verwachten (het is intuïtief in het gebruik al weet je misschien niet direct waarom) en dat heeft weer tot gevolg dat je hier op een natuurlijke manier mee kunt rekenen en vergelijken.
Wellicht zie je nu waarom het op voorhand formatteren van een datum (22/03/2018 16:42:43) nogal bagger is, je kunt hier totaal niet mee rekenen of sorteren.
Daarnaast het volgende: wat als je op enig moment besluit om deze formattering te wijzigen of dat dit een persoonlijke voorkeur wordt? Wat doe je dan met al deze datums in een vastgebakken formaat? Ga je dan allerlei lijpe queries draaien om deze zooi te updaten? Wat hier in wezen gebeurt is HARDCODING van data in een uiterst onhandig formaat.
In het algemeen is het vele malen verstandiger om alle data zo rauw/ongewijzigd/neutraal mogelijk op te slaan. In welke vorm je vervolgens een datum presenteert kun je tot op het moment voor weergave uitstellen, en hier dan een formatteringsfunctie (in PHP) op loslaten. Dit hoef je niet in de database te regelen, en dat zou je ook niet moeten willen om voorgenoemde redenen.
En ook: je database vormt het fundament van je applicatie, het is daarom zeer belangrijk dat je goed nadenkt WAAROM je bepaalde dingen op een bepaalde manier oplost en vormgeeft, en niet zomaar iets de flavour-of-the-month geeft.
Ik moet ook helaas toegeven dat deze manier voor het formatteren van datums toch een beetje een gotcha voor beginners is... In het vervolg ~5 minuten langer nadenken hoe de structuur van een tabel eruitziet (en WAAROM) kan je later veel kopzorgen schelen.
Of stel jezelf de vragen:
- WAT wil ik met deze data uiteindelijk kunnen doen, en (vervolgens)
- HOE trek ik deze data uit de database?
Als je ontwerp zodanig is dat je niet of niet makkelijk antwoorden kunt geven op deze vragen (ook letterlijk: hoe de queries er uit zouden moeten zien om antwoord te geven op gewenste informatie of overzichten uit de database) dan is het (de) hoog(ste) tijd om je ontwerp te herzien.
Gewijzigd op 22/03/2018 17:56:52 door Thomas van den Heuvel
