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.
Dat is een mooie, enige puntje is dat hij het niet altijd moet replacen. Op het moment voert hij eerst een DELETE query uit, waarbij er enkele unieke eigenschappen moeten matchen (ik werk dus helaas niet op ID). Daarna een Insert, met dezelfde unieke eigenschappen, en nog enkele andere gegevens.quote:Op donderdag 22 februari 2007 14:08 schreef GI het volgende:
[..]
http://dev.mysql.com/doc/refman/5.0/en/replace.html
Er is dus niet altijd een record aanwezig met de eigenschappen die bij de delete matchen, alleen het inserten is iets dat altijd moet. Dus wat ik mij afvroeg: Is het netjes om de twee queries achter elkaar te plakken?
niet echt een php vraagje, maar hoe kan ik in flash dezelfde xml-file opnieuw inladen zonder de pagina te herladen?
het xml bestand wordt onLoad geladen en ik dmv ajax zet ik een paar variabelen die in de xml komen te staan.
nu wil ik deze xml opnieuw inladen maar als ik dan document.flash_movie.Play(); doe laad ie dezelfde waarden in, als ik op F5 druk is het wel aangepast.
iemand een idee?
flash is niet zo mijn ding
het xml bestand wordt onLoad geladen en ik dmv ajax zet ik een paar variabelen die in de xml komen te staan.
nu wil ik deze xml opnieuw inladen maar als ik dan document.flash_movie.Play(); doe laad ie dezelfde waarden in, als ik op F5 druk is het wel aangepast.
iemand een idee?
flash is niet zo mijn ding
waarom wil je dit in 1 query doen? Voordat het qua performance wat uitmaakt moet je het wel heel veel records updatenquote:Op donderdag 22 februari 2007 14:18 schreef Geqxon het volgende:
[..]
Dat is een mooie, enige puntje is dat hij het niet altijd moet replacen. Op het moment voert hij eerst een DELETE query uit, waarbij er enkele unieke eigenschappen moeten matchen (ik werk dus helaas niet op ID). Daarna een Insert, met dezelfde unieke eigenschappen, en nog enkele andere gegevens.
hoe wordt de XML ingelezen?quote:Op donderdag 22 februari 2007 16:58 schreef Tiemie het volgende:
nu wil ik deze xml opnieuw inladen maar als ik dan document.flash_movie.Play(); doe laad ie dezelfde waarden in, als ik op F5 druk is het wel aangepast.
Misschien zit die in een functie die alleen aangeroepen wordt als er nog niks ingeladen is? Waardoor die bij de 2x keer dus niks doet en gewoon de oude data gebruikt.
Als het bestand de 2e keer 'echt' wordt geladen zou die gewoon de nieuwe waarden moeten bevatten
Schoonheidsperfectiequote:Op donderdag 22 februari 2007 23:32 schreef Xcalibur het volgende:
[..]
waarom wil je dit in 1 query doen? Voordat het qua performance wat uitmaakt moet je het wel heel veel records updaten
lijkt me lastig, als je niet van tevoren weet of er een record te updaten is... als je hem al hebt is het gemakkelijker, maar dan heb je in principe al eerder een select gedaan
Het gaat bij mij om een cache-script. Om het script uit te leggen:
Eerst kijken of de gezochte data in de database bestaat, en kijken hoe recent deze data is.
Als de data gevonden is, en jonger dan 24 uur is >>> Laden
Als de data niet gevonden is, of ouder dan 24 uur >>> Uit een exterene website laden, de delete query gevolgd door de insert query om de vers opgehaalde data in de database te stoppen.
Werkt prima, maar imho wil ik het net ietsjes strakker hebben. Vandaar. Maar ik zie al een optie, namelijk de check om te kijken of de data uberhaupt wel bestaat (mysql_num_rows), gaat goed komen.
Werkt prima, maar imho wil ik het net ietsjes strakker hebben. Vandaar. Maar ik zie al een optie, namelijk de check om te kijken of de data uberhaupt wel bestaat (mysql_num_rows), gaat goed komen.
Gewoon een query maken die als extra eis meeneemt dat de data niet ouder dan 24 uur mag zijn. Als je de datum in een DATETIME of een Unix Timestamp (unsigned int) opslaat dan moet dat lukken.quote:Op vrijdag 23 februari 2007 00:12 schreef Geqxon het volgende:
Het gaat bij mij om een cache-script. Om het script uit te leggen:Eerst kijken of de gezochte data in de database bestaat, en kijken hoe recent deze data is. Als de data gevonden is, en jonger dan 24 uur is >>> Laden Als de data niet gevonden is, of ouder dan 24 uur >>> Uit een exterene website laden, de delete query gevolgd door de insert query om de vers opgehaalde data in de database te stoppen.
Werkt prima, maar imho wil ik het net ietsjes strakker hebben. Vandaar. Maar ik zie al een optie, namelijk de check om te kijken of de data uberhaupt wel bestaat (mysql_num_rows), gaat goed komen.
dan heb je wel een extra query nodig om de data ouder dan 24 uur op te zoeken en weg te gooien...quote:Op vrijdag 23 februari 2007 08:37 schreef Light het volgende:
Gewoon een query maken die als extra eis meeneemt dat de data niet ouder dan 24 uur mag zijn. Als je de datum in een DATETIME of een Unix Timestamp (unsigned int) opslaat dan moet dat lukken.
Tenzij je die niet weggooit natuurlijk
Draai die 'opschoonquery' 1 keer per dag ofzo zou ik zeggen. Dat maakt het allemaal een stuk eenvoudiger denk ik.quote:Op vrijdag 23 februari 2007 09:11 schreef Xcalibur het volgende:
[..]
dan heb je wel een extra query nodig om de data ouder dan 24 uur op te zoeken en weg te gooien...
Tenzij je die niet weggooit natuurlijk
Om jullie allemaal maar te beantwoorden:
-In de tabel heb ik al een kolom met daarin de waarde van nu + 24 uur. In de query staat dus feitelijk
Zodra ik geen resultaten met de select-query krijg, betekend dat dus twee dingen:
-De data is staat niet in de database
-De data is ouder dan 24 uur.
In dat geval schiet hij dus de else-statement in, waar hij de volgende dingen doet:
-De data van een externe website ophalen (traag!)
-De oude data weggooien (of iig een poging tot)
-De versgehaalde data in de database stoppen
De opschoonquery is daarom dus niet nodig, aangezien de data bij de eerstvolgende search automatisch geupdate zal worden. Leuk systeem, en het draait prima. Enige wat ik dus ga vervangen is het kijken waarom hij de data niet op kan halen, hoe dat dus komt. En aan de hand daarvan dus de juiste query draaien.
-In de tabel heb ik al een kolom met daarin de waarde van nu + 24 uur. In de query staat dus feitelijk
| 1 2 3 | " WHERE Expires > " . time() . " ?> |
Zodra ik geen resultaten met de select-query krijg, betekend dat dus twee dingen:
-De data is staat niet in de database
-De data is ouder dan 24 uur.
In dat geval schiet hij dus de else-statement in, waar hij de volgende dingen doet:
-De data van een externe website ophalen (traag!)
-De oude data weggooien (of iig een poging tot)
-De versgehaalde data in de database stoppen
De opschoonquery is daarom dus niet nodig, aangezien de data bij de eerstvolgende search automatisch geupdate zal worden. Leuk systeem, en het draait prima. Enige wat ik dus ga vervangen is het kijken waarom hij de data niet op kan halen, hoe dat dus komt. En aan de hand daarvan dus de juiste query draaien.
Omdat "time()" de huidige waarde in de vorm van een UNIX timestamp presenteert. Het veld "Expires" is dan ook een doodsimpele integer van 11 tekens lang, in plaats van het imho bloated MySQL date format.
Dat is toch enorm onhandig
Trouwens, nu ik hier toch ben
Ik ben bezig met een soort van CMS, maar het lukt me niet om paragrafen netjes te krijgen. Ik kan wel nl2br gebruiken, maar ik heb liever dat er van zelf paragrafen worden gemaakt van de nieuwe lijnen zonder zelf html of ubb in te voeren.
Trouwens, nu ik hier toch ben
Ik ben bezig met een soort van CMS, maar het lukt me niet om paragrafen netjes te krijgen. Ik kan wel nl2br gebruiken, maar ik heb liever dat er van zelf paragrafen worden gemaakt van de nieuwe lijnen zonder zelf html of ubb in te voeren.
quote:Op vrijdag 23 februari 2007 10:08 schreef Geqxon het volgende:
Omdat "time()" de huidige waarde in de vorm van een UNIX timestamp presenteert. Het veld "Expires" is dan ook een doodsimpele integer van 11 tekens lang, in plaats van het imho bloated MySQL date format.
Goh er zitten ook - in je database veld... wat bloated. En je kan er ongeveer 1000 keer handiger mee uit de voeten.
Afhankelijk van hoe je je CMS in elkaar hebt gezet kun je ervoor kiezen om twee opeenvolgende line breaks om te toveren in een nieuwe paragraaf? Dan moet je natuurlijk wel de paragrafen tekst goed bepalen, omdat je daar de <p>...</p> omheen moet zettenquote:Op vrijdag 23 februari 2007 10:56 schreef super-muffin het volgende:
Ik ben bezig met een soort van CMS, maar het lukt me niet om paragrafen netjes te krijgen. Ik kan wel nl2br gebruiken, maar ik heb liever dat er van zelf paragrafen worden gemaakt van de nieuwe lijnen zonder zelf html of ubb in te voeren.
Ieder zijn ding. Ik werk liever gewoon met timestamps als integers, universeel. Pas bij het tonen in de browser zet ik het in DD-MM-YYYY formaat.quote:Op vrijdag 23 februari 2007 11:06 schreef Swetsenegger het volgende:
[..]
Goh er zitten ook - in je database veld... wat bloated. En je kan er ongeveer 1000 keer handiger mee uit de voeten.
Een integer van 11 tekens lang?quote:Op vrijdag 23 februari 2007 10:08 schreef Geqxon het volgende:
Het veld "Expires" is dan ook een doodsimpele 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.
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.quote:Op vrijdag 23 februari 2007 11:06 schreef Swetsenegger het volgende:
[..]
Goh er zitten ook - in je database veld... wat bloated. En je kan er ongeveer 1000 keer handiger mee uit de voeten.
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?
Hey,
Nu moet ik ineens voor school bezig met PHP een aantal oprdachten maken waaronder de basis van cookies. Wanneer ik een script maak met een cookie er in, en het in xampp laad gebeurd er niets. Weet iemand toevallig of cookies aangezet moeten worden in xampp ofzo?
Ik heb zelf mijn internet explorer al ingesteld dat er een prompt komt wanneer een cookie opgeslagen zou moeten worden. Maar hij prompt ook niet.
Nu moet ik ineens voor school bezig met PHP een aantal oprdachten maken waaronder de basis van cookies. Wanneer ik een script maak met een cookie er in, en het in xampp laad gebeurd er niets. Weet iemand toevallig of cookies aangezet moeten worden in xampp ofzo?
Ik heb zelf mijn internet explorer al ingesteld dat er een prompt komt wanneer een cookie opgeslagen zou moeten worden. Maar hij prompt ook niet.
Laat eens wat code zien? Dan weten we ook meteen hoe je je cookies probeert op te slaan. Er is niet zoiets als het activeren van cookies in PHP, aangezien het in feite een HTTP-header is.quote:Op vrijdag 23 februari 2007 19:01 schreef Wiehoe het volgende:
Nu moet ik ineens voor school bezig met PHP een aantal oprdachten maken waaronder de basis van cookies. Wanneer ik een script maak met een cookie er in, en het in xampp laad gebeurd er niets. Weet iemand toevallig of cookies aangezet moeten worden in xampp ofzo?
Ik heb zelf mijn internet explorer al ingesteld dat er een prompt komt wanneer een cookie opgeslagen zou moeten worden. Maar hij prompt ook niet.
| 1 2 3 4 5 6 7 | $count++; setcookie('count', $count); error_reporting(E_ALL); echo($count); ?> |
Dit moet dus oplopen volgens zo'n php boek.
Allereerst zul je de superglobal $_COOKIE['count'] moeten gebruiken om de cookie op te vragen. Verder is het slim om een expire time op te geven in setcookie, zoiets als dit:quote:Op vrijdag 23 februari 2007 19:54 schreef Wiehoe het volgende:
[ code verwijderd ]
Dit moet dus oplopen volgens zo'n php boek.
Bedankt, ik heb dit er van gemaakt, en het werkt:
Ik vind het overigens maar raar dat het dan in zo'n boek helemaal verkeerd staat beschreven. En dan geven ze wel specifiek aan dat er geen enter gelijk na de <?php mag komen. omdat die dan een Warning aangeeft.
| 1 2 3 4 5 6 7 | $count = $_COOKIE['count'] + 1; setcookie('count', $count, time() + 3600); error_reporting(E_ALL); echo $_COOKIE['count']; ?> |
Ik vind het overigens maar raar dat het dan in zo'n boek helemaal verkeerd staat beschreven. En dan geven ze wel specifiek aan dat er geen enter gelijk na de <?php mag komen. omdat die dan een Warning aangeeft.
Daarom ben ik ook absoluut geen fan van boeken om een taal te leren, zeker niet als de taal zelf in constante ontwikkeling is.quote:Op vrijdag 23 februari 2007 20:02 schreef Wiehoe het volgende:
Ik vind het overigens maar raar dat het dan in zo'n boek helemaal verkeerd staat beschreven.
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 ]
