DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
nog een reden om gewoon datetime te gebruiken.quote:Op vrijdag 23 februari 2007 17:52 schreef JeRa het volgende:
[..]
Niet eens, MySQL slaat tijd en datum intern ook op aan de hand van timestamps. Op het moment dat je een SELECT doet of de waarden vergelijkt aan de hand van zo'n datum/tijd dan zet MySQL de boel automagisch om naar een bepaalde representatie.
Niets méér, wel makkelijker met de datesub functie van mysql en dergelijke.quote:Verder ben ik benieuwd naar wat jij denkt meer te kunnen met een DATETIME / TIMESTAMP veld dan met een eigen timestamp die pas in de frontend voor presentatie wordt omgezet?
Is het niet zo dat met INT(11) ik elke keer 11 tekens aan geheugen reserveer?quote:Op vrijdag 23 februari 2007 17:50 schreef JeRa het volgende:
[..]
Een integer van 11 tekens lang?
Een INT(11) betekent niets anders dan dat je een integer veld hebt die bij een geactiveerde optie ZEROFILL een getal weergeeft dat wordt geprepad met nullen totdat het 11 nummers bevat. Zonder die optie betekent die 11 helemaal niéts.
Daarom is het ook zo dat ik het persoonlijk fijner vind. Zo maakt phpMyAdmin bv. er weer "03 December 2007" van, moet ik het bij query's weer omzetten met MYSQL_DATEFORMAT (oid) enz. enz. Ik moet bekennen dat ik er al lang niet mee gewerkt hebt, dus ik kan niet concreet zijn met mijn voorbeelden.quote:Op vrijdag 23 februari 2007 17:52 schreef JeRa het volgende:
[..]
Niet eens, MySQL slaat tijd en datum intern ook op aan de hand van timestamps. Op het moment dat je een SELECT doet of de waarden vergelijkt aan de hand van zo'n datum/tijd dan zet MySQL de boel automagisch om naar een bepaalde representatie.
Verder ben ik benieuwd naar wat jij denkt meer te kunnen met een DATETIME / TIMESTAMP veld dan met een eigen timestamp die pas in de frontend voor presentatie wordt omgezet?
Ik heb er in het verleden redelijk wat last van gehad, vandaar dat ik het nu weer gewoon met integers doe, en het pas in de frontend omzet. Zo kan ik er ook makkelijk mee rekenen
Nadeel is wel dat MySQL (vaak overbodige) informatie opslaat zoals milliseconden en timezones en dus meer schijfruimte nodig heeft om iets op te slaan wat je waarschijnlijk nooit nodig zult hebben. Als je veel om performance geeft en je ontzettend veel records hebt (miljoenen in mijn geval) wil je de DATETIME toch echt vermijdenquote:Op vrijdag 23 februari 2007 20:53 schreef Swetsenegger het volgende:
[..]
nog een reden om gewoon datetime te gebruiken.
Dat is relatief, het ligt er maar net aan waar je de bewerkingen doet. Ik vind het persoonlijk veel gemakkelijker om alle tijdsberekeningen met unix epoch timestamps in PHP te doen en MySQL de resultaten daarvan te voeren in plaats van date/time strings aan MySQL door te geven. 90% van de dingen die ik zo doe gaan gemakkelijker (en ook duidelijker in de code) door timestamps te gebruiken, en voor die overige 10% gebruik ik timestamp -> datetime conversies in MySQL (dezelfde die MySQL impliciet toch al zou gebruiken als je DATETIME gebruikt)quote:[..]
Niets méér, wel makkelijker met de datesub functie van mysql en dergelijke.
Bij lange na niet, een signed of unsigned integer in MySQL neemt gewoon 4 bytes in beslag die 11 is alléén voor ZEROFILL, that's it.quote:Op vrijdag 23 februari 2007 20:56 schreef Geqxon het volgende:
[..]
Is het niet zo dat met INT(11) ik elke keer 11 tekens aan geheugen reserveer?
Ik ben ook iemand van presentatie in de presentatielaag en niet in de opslaglaag, dus ik zou ook voor de timestamps gaan. Een RDBMS zie ik als een handig systeem om snel informatie aan elkaar te koppelen, maar wat ik vervolgens met die informatie doe laat ik toch echt aan de presentatielaag overquote:[..]
Daarom is het ook zo dat ik het persoonlijk fijner vind. Zo maakt phpMyAdmin bv. er weer "03 December 2007" van, moet ik het bij query's weer omzetten met MYSQL_DATEFORMAT (oid) enz. enz. Ik moet bekennen dat ik er al lang niet mee gewerkt hebt, dus ik kan niet concreet zijn met mijn voorbeelden.
Ik heb er in het verleden redelijk wat last van gehad, vandaar dat ik het nu weer gewoon met integers doe, en het pas in de frontend omzet. Zo kan ik er ook makkelijk mee rekenen
Wat mij van Oracle SQL bij staat, is dat als ik een Varchar2(30) in mijn database heb, dat hij dan altijd 30 tekens aan geheugen inneemt, ongeacht wat er in staat. Daarom is het juist zo belangrijk dat je kijkt welke data in je database komt, en hoe groot dat normaliter is. Maar dat is zo te horen dus niet met MySQL integersquote:Op vrijdag 23 februari 2007 21:02 schreef JeRa het volgende:
[..]
Bij lange na niet, een signed of unsigned integer in MySQL neemt gewoon 4 bytes in beslag die 11 is alléén voor ZEROFILL, that's it.
Daar gaat iets helemaal foutquote:Op vrijdag 23 februari 2007 21:07 schreef Geqxon het volgende:
[..]
Wat mij van Oracle SQL bij staat, is dat als ik een Varchar2(30) in mijn database heb, dat hij dan altijd 30 tekens aan geheugen inneemt, ongeacht wat er in staat. Daarom is het juist zo belangrijk dat je kijkt welke data in je database komt, en hoe groot dat normaliter is. Maar dat is zo te horen dus niet met integers
Een VARCHAR2 (achterlijke benaming trouwens, ach ja ) neemt net zoveel tekens in beslag als de string lang is die wordt opgeslagen, echter is dat tot een maximum van 30 tekens. Een CHAR neemt áltijd 30 tekens in beslag, want kortere strings krijgen spaties aan het einde totdat er 30 tekens in beslag worden genomen.
Een INT is echter een compleet ander verhaal, die kun je niet zomaar variabele lengten geven omdat de capaciteit daarvan vervolgens exponentieel toeneemt en de meeste processoren niet zo goed omgaan met 80-bits integers, enzo verwarrend dus, maar voor die zerofill feature is het toch zo gedaan.
Lees de TT nog eens JeRa vooral na de blokhakenquote:Op vrijdag 23 februari 2007 21:00 schreef JeRa het volgende:
[..]
Nadeel is wel dat MySQL (vaak overbodige) informatie opslaat zoals milliseconden en timezones en dus meer schijfruimte nodig heeft om iets op te slaan wat je waarschijnlijk nooit nodig zult hebben. Als je veel om performance geeft en je ontzettend veel records hebt (miljoenen in mijn geval) wil je de DATETIME toch echt vermijden
Voordat ik wist dat mysql van die handige datum functies had deed ik ook zo ingewikkeldquote:Dat is relatief, het ligt er maar net aan waar je de bewerkingen doet. Ik vind het persoonlijk veel gemakkelijker om alle tijdsberekeningen met unix epoch timestamps in PHP te doen en MySQL de resultaten daarvan te voeren in plaats van date/time strings aan MySQL door te geven. 90% van de dingen die ik zo doe gaan gemakkelijker (en ook duidelijker in de code) door timestamps te gebruiken, en voor die overige 10% gebruik ik timestamp -> datetime conversies in MySQL (dezelfde die MySQL impliciet toch al zou gebruiken als je DATETIME gebruikt)
Waarom laat je MySQL niet meteen alle HTML genereren?quote:Op vrijdag 23 februari 2007 21:17 schreef Swetsenegger het volgende:
[..]
Lees de TT nog eens JeRa vooral na de blokhaken
[..]
Voordat ik wist dat mysql van die handige datum functies had deed ik ook zo ingewikkeld
kom kom... beetje nuanceren mag wel. De datum functies van mysql zijn gewoon verdomd handig voor wat de gemiddelde hobby-ist er mee doet.quote:Op vrijdag 23 februari 2007 21:20 schreef JeRa het volgende:
[..]
Waarom laat je MySQL niet meteen alle HTML genereren?
De functies die PHP biedt leveren ook een scala aan mogelijkheden, de vraag is waarom je de datum/tijd representatie in de opslaglaag al wilt hebben en niet pas bij de presentatie. Enerzijds valt er wat voor te zeggen voor het type data (je gebruikt een veld met een bepaald type om data met een bepaald type op te slaan) maar anderzijds is het voor veel dummies een stuk gemakkelijker om simpelweg te vergelijken tussen secondes aangezien ontzettend veel elementen in PHP dit ook vereisenquote:Op vrijdag 23 februari 2007 21:23 schreef Swetsenegger het volgende:
[..]
kom kom... beetje nuanceren mag wel. De datum functies van mysql zijn gewoon verdomd handig voor wat de gemiddelde hobby-ist er mee doet.
Ik gebruik het tot op heden alleen om zaken van een dag geleden (of een week of een maand) uit de database te trekken. dan is datesub gewoon verdomd handig. Ik hoef niet eerst in php de tijd te definieren voordat ik iets uit mijn db trek.quote:Op vrijdag 23 februari 2007 21:30 schreef JeRa het volgende:
[..]
De functies die PHP biedt leveren ook een scala aan mogelijkheden, de vraag is waarom je de datum/tijd representatie in de opslaglaag al wilt hebben en niet pas bij de presentatie. Enerzijds valt er wat voor te zeggen voor het type data (je gebruikt een veld met een bepaald type om data met een bepaald type op te slaan) maar anderzijds is het voor veel dummies een stuk gemakkelijker om simpelweg te vergelijken tussen secondes aangezien ontzettend veel elementen in PHP dit ook vereisen
Nee, in plaats daarvan definiëer je 'm in de opslaglaag. Ik zie geen verschil.quote:Op vrijdag 23 februari 2007 21:35 schreef Swetsenegger het volgende:
[..]
Ik gebruik het tot op heden alleen om zaken van een dag geleden (of een week of een maand) uit de database te trekken. dan is datesub gewoon verdomd handig. Ik hoef niet eerst in php de tijd te definieren voordat ik iets uit mijn db trek.
Het bespaart me moeite want met een timestamp moet ik nadenken enquote:Op vrijdag 23 februari 2007 21:46 schreef JeRa het volgende:
[..]
Nee, in plaats daarvan definiëer je 'm in de opslaglaag. Ik zie geen verschil.
WHERE thedate<=DATE_SUB(NOW(), INTERVAL 1 DAY)
is gewoon easy en gemakkelijk en helder leesbaar enzo. Dat snap ik over een jaar nog Al dat gereken met microsecondes heb ik als voormalig uurwerkmaker een pleurishekel.
Ik bedoel, het hele idee van microtime is om te huilen natuurlijk. Het aantal microseconden verstreken sinds 1 januari 1970? Welke bosmongool heeft dat verzonnen? Hou dan in godesnaam gewoon de algemeen geaccepteerde epoch aan van 01-01-0000.
Niet... dat gekut met tijd in php is gewoon ranzig.quote:Op vrijdag 23 februari 2007 21:57 schreef Geqxon het volgende:
Nu we toch over timestamps aan het miepen zijn
[ code verwijderd ]
Het resultaat? De timestamp van vandaag, exact op 00:00:00. Ik vind het enorm ranzige code, en vroeg mij af hoe ik dat netter ga krijgen?
strtotime('00:00') ofzo?quote:Op vrijdag 23 februari 2007 21:57 schreef Geqxon het volgende:
Nu we toch over timestamps aan het miepen zijn
[ code verwijderd ]
Het resultaat? De timestamp van vandaag, exact op 00:00:00. Ik vind het enorm ranzige code, en vroeg mij af hoe ik dat netter ga krijgen?
Gelukkig hebben we ook negatieve timestampsquote:Op vrijdag 23 februari 2007 21:59 schreef Swetsenegger het volgende:
[..]
Het bespaart me moeite want met een timestamp moet ik nadenken en
WHERE thedate<=DATE_SUB(NOW(), INTERVAL 1 DAY)
is gewoon easy en gemakkelijk en helder leesbaar enzo. Dat snap ik over een jaar nog Al dat gereken met microsecondes heb ik als voormalig uurwerkmaker een pleurishekel.
Ik bedoel, het hele idee van microtime is om te huilen natuurlijk. Het aantal microseconden verstreken sinds 1 januari 1970? Welke bosmongool heeft dat verzonnen? Hou dan in godesnaam gewoon de algemeen geaccepteerde epoch aan van 01-01-0000.
Nee, javascript is daar lekker inquote:Op vrijdag 23 februari 2007 22:00 schreef Swetsenegger het volgende:
[..]
Niet... dat gekut met tijd in php is gewoon ranzig.
Ehm, waarom begin je opeens over microtime? time() is voldoende hoor en het refereert natuurlijk naar de standaard Unix times, die vooral op unix-like systemen wordt gebruikt.quote:Op vrijdag 23 februari 2007 21:59 schreef Swetsenegger het volgende:
[..]
Het bespaart me moeite want met een timestamp moet ik nadenken en
WHERE thedate<=DATE_SUB(NOW(), INTERVAL 1 DAY)
is gewoon easy en gemakkelijk en helder leesbaar enzo. Dat snap ik over een jaar nog Al dat gereken met microsecondes heb ik als voormalig uurwerkmaker een pleurishekel.
Ik bedoel, het hele idee van microtime is om te huilen natuurlijk. Het aantal microseconden verstreken sinds 1 januari 1970? Welke bosmongool heeft dat verzonnen? Hou dan in godesnaam gewoon de algemeen geaccepteerde epoch aan van 01-01-0000.
Ik ruik een tweede milenium bug... en dat is waarom mijn opa altijd zei: DD-MM-YYYY !quote:Note: If the number of the year is specified in a two digit format, the values between 0-69 are mapped to 2000-2069 and 70-100 to 1970-2000.
Nog steeds gezeikquote:Op vrijdag 23 februari 2007 22:13 schreef JeRa het volgende:
[..]
Ehm, waarom begin je opeens over microtime? time() is voldoende hoor en het refereert natuurlijk naar de standaard Unix times, die vooral op unix-like systemen wordt gebruikt.
En erger... ik win er niets mee.
Ontzettend handig als je relatief wilt werken, bijvoorbeeld wilt weten hoeveel tijd er tussen twee data zit. Als je dat wilt doen met DATETIME moet je eerst allerlei vage conversiefuncties gaan gebruikenquote:
SELECT unix_timestamp(date1) -quote:Op vrijdag 23 februari 2007 22:18 schreef JeRa het volgende:
[..]
Ontzettend handig als je relatief wilt werken, bijvoorbeeld wilt weten hoeveel tijd er tussen twee data zit. Als je dat wilt doen met DATETIME moet je eerst allerlei vage conversiefuncties gaan gebruiken
unix_timestamp(date2) FROM table_name
Maar dat klopt als je wil weten wat er voor tijd vertstreken is tussen twee records is dat lastig. Maar ik wil voor mijn huidige toepassingen altijd weten hoeveel tijd er tussen en record en NU zit. En daar zijn de mysql functies gewoon verdomd handig voor
Ik gebruik altijd int's voor timestamps...waarom? omdat 9 v/d 10x de database de bottleneck is in een (grote) website. de database is voor mij puur voor de opslag.
Ik ben bezig met een template parser. Nou loop ik alleen tegen een probleem aan de code doet vervangt de waardes uit de template niet:
$tags is een class array met de tags uit de template en de vervang data. Als ik alle delen afzondelijk echo krijg ik ze gewoon te zien. Alleen het replacen gaat niet goed.
Laat maar ik ben nog slaperig. Moet natuurlijk zijn
[ Bericht 12% gewijzigd door ExCibular op 24-02-2007 09:52:02 ]
| 1 2 3 | str_replace("<%$tag%>" , $data , $this->output); } |
$tags is een class array met de tags uit de template en de vervang data. Als ik alle delen afzondelijk echo krijg ik ze gewoon te zien. Alleen het replacen gaat niet goed.
Laat maar ik ben nog slaperig. Moet natuurlijk zijn
| 1 |
[ Bericht 12% gewijzigd door ExCibular op 24-02-2007 09:52:02 ]
