[php, mysql] Poll die actief gaat dmv datum

[Jboy1991]

Goedendag,

Ik ben druk bezig met het maken van een poll systeem voor mn site die actief gaat d.m.v datums. Zo kan ik bijv polls laten sluiten op X datum en een nieuwe poll starten op datum Y

Echter loop ik nu vast. Hoe kan ik het beste checken of tussen de nieuwe(aangemaakte) poll en recent toegevoegde polls genoeg tijd zit.

Ik heb dus in mijn mysql twee tabellen bij de polls P_START en P_END.

Nu vroeg ik een poll toe met datum 02-5-2017 en die loopt T/M 6-5-2017.

Toevoegen is voltooid en dan nu het probleem:
Wanneer ik een nieuwe poll toevoeg die begint op 30-4-2017 en loopt tot 5-5-2017 hoor ik een error te krijgen. Dit omdat de eind datum tussen een eerder gestarte poll valt. Maar dit stukje lukt mij dus niet.


Wel is het mij gelukt om te checken of de start datum tussen een al toegevoegde poll valt:

code:

    $check_query_sql = "SELECT * FROM poll_db WHERE '".date('Y-m-d', strtotime( mysql_real_escape_string( $date)))."' between P_START and P_END";

Iemand een idee hoe ik het het beste kan oplossen?

[McKaamos]

Ik denk dat dat komt doordat je met datums werkt, en MySQL's Between functie is numeriek, niet datum gebaseerd.
Je zal dus je datum moeten omzetten naar een numeriek formaat. Een hele goede optie daar voor is het gebruik van Unix Timestamp.
Dat is namelijk een 32bit unsigned INT die secondes telt vanaf de Unix Epoch. Dat was 00:00 op 01-01-1970.

Als je de P_Start en P_End datums omzet naar Unix Timestamp, staan ze dus opgeslagen als Integer.
Als je je gewenste datum dan ook ingeeft als Unix Timestamp, kan Between er mee overweg omdat alle waardes Integer zijn.

[Jboy1991]

McKaamos schreef op zaterdag 29 april 2017 @ 17:09:
Ik denk dat dat komt doordat je met datums werkt, en MySQL's Between functie is numeriek, niet datum gebaseerd.
Je zal dus je datum moeten omzetten naar een numeriek formaat. Een hele goede optie daar voor is het gebruik van Unix Timestamp.
Dat is namelijk een 32bit unsigned INT die secondes telt vanaf de Unix Epoch. Dat was 00:00 op 01-01-1970.

Als je de P_Start en P_End datums omzet naar Unix Timestamp, staan ze dus opgeslagen als Integer.
Als je je gewenste datum dan ook ingeeft als Unix Timestamp, kan Between er mee overweg omdat alle waardes Integer zijn.

Ah nou het lijkt erop dat het werkt. Wel minder dat ik nu in de mysql de data niet kan aflezen maar wanneer het eenmaal af is heb je met phpmyadmin niet zoveel meer te maken

Bedankt

[McKaamos]

Jboy1991 schreef op zaterdag 29 april 2017 @ 17:16:
[...]

Ah nou het lijkt erop dat het werkt. Wel minder dat ik nu in de mysql de data niet kan aflezen maar wanneer het eenmaal af is heb je met phpmyadmin niet zoveel meer te maken

Bedankt

Nou, dat kan eigenlijk wel.
Ik ben zo even kwijt hoe dat ook alweer moest en hoe het heet, maar je kan de weergave per tabel anders laten doen dan de daadwerkelijke opslag.

Oh en nog een klein dingetje, als je direct een datum omzet naar Unix Timestamp, zonder daarbij een tijdstip op te geven, dan zal hij de eerste seconde van die dag nemen.
Als je einddatum een tot-en-met datum is, dan moet je daar nog even 86399 bij op tellen. (24uur * 60min * 60sec - 1sec).
Dan is die einddatum effectief datum met tijdstip 23:59:59 geworden en kan je met de between functie direct selecteren.

[Ofyles2]

Zelf ook vaak gewerkt met DATEDIFF. Timestamps gebruik ik eigenlijk alleen in PostgreSQL.

[Jantje2000]

Ik gebruik daarvoor inderdaad date diff functie zoals Ofyles2 al zegt.
een voorbeeld is:

PHP:

<?php
$first_date = new DateTime("27-4-2017 14:56:33");

$second_date = new DateTime("29-4-2017 13:54:56");

$difference = $first_date->diff($second_date);

print "Het verschil is " . $difference->y . " jaar, " . $difference->m . " maand(en), " . $difference->d . " dag(en), " . $difference->h . " uur, " . $difference->i . " minuten en " . $difference->s . " seconden";

?>

Dit laat zien wat het verschil is tussen twee datums. Dit zou je dan om kunnen zetten in seconden of minuten o.i.d., zodat je daarna kan checken of dat meer minuten zijn dan het moesten zijn, of iets dergelijks.

Iets wat niet direct met de vraag te maken heeft, maar wat ik wel als tip wil geven: Na PHP5 kun je de mysql_* functies niet meer gebruiken. Stap daarom nu al over naar PDO of MySQLi, om compatible(r) te zijn met de volgende PHP functies.

[ Voor 15% gewijzigd door Jantje2000 op 29-04-2017 19:37 ]

[Jboy1991]

Jantje2000 schreef op zaterdag 29 april 2017 @ 19:34:


Iets wat niet direct met de vraag te maken heeft, maar wat ik wel als tip wil geven: Na PHP5 kun je de mysql_* functies niet meer gebruiken. Stap daarom nu al over naar PDO of MySQLi, om compatible(r) te zijn met de volgende PHP functies.

Oh echt? Iknheb xammp hier draaien en nergens last van met php5. Is het moeilijk om alles om te zetten? Of is het het zelfde idee

[Jantje2000]

Jboy1991 schreef op zaterdag 29 april 2017 @ 21:15:
[...]

Oh echt? Iknheb xammp hier draaien en nergens last van met php5. Is het moeilijk om alles om te zetten? Of is het het zelfde idee

Ik zei NA PHP5 . Dus dit gaat dan over PHP 7 en volgende versies. Het is makkelijk over te zetten, maar er zijn wel een paar functies die in PHP7 niet meer zullen werken. Een voorbeeld daarvan is mysql_*.

[switchboy]

mysql_ is dan ook antiek en ondersteund geen prepared statements, hierdoor is de code die he schrijft gevoelliger voor mysql injectie. (kwaadwillende code die door middel van je formulieren op de mysql server uitgevoerd kan worden.

Stel je hebt als script:

PHP:

<?php

//rest van de code

$id = $_POST['id']
$result = mysql_query("SELECT * FROM `table1` WHERE id = '$id' ");
$row = mysql_fetch_array($result);

//rest van de code

//Hoe zou je het in PDO doen?

$result = $PDO->prepare("SELECT * FROM `table1` WHERE id = :id");
$result->execute(array(':id' => $id));
$row = $result->fetchAll();

?>

en ik zou hier "0'; DROP DATABASE" naartoe sturen, dan zijn alle gegevens uit je database weg. Dit kan je ondervangen door de string $id 'veilig' te maken door alle speciale karakters zoals ' " enz te escapen met verschillende functies. Maar beter is het hele mysql_* te vergeten en mysqli of PDO voor de verbinding met de database te gebruiken. Bij een prepared statement wordt het mysql commando en de informatie niet meer samen als platte tekst naar de server gestuurd. Hierdoor heeft SQL injectie geen kans.

Maar let op: Als je de data ruw opslaat in je database en dan on aagepast aan de gebruiker voorschotelt blijft je natuurlijk wel vatbaar voor HTML/javascript injectie. Hiermee wordt kwaadwillende code via jouw website in de browser van je bezoeker gedraaid. Dit kan iets onschuldigs als een defacing zijn. Maar ook een redirect of code met een exploit en een trojan als payload.

Alhoewel je in jouw code nu je UNIX timestamps via strtotime() gebruikt in dit hele specifieke geval wel veilig bent voor injectie volgensmij

[RiDo78]

Jboy1991 schreef op zaterdag 29 april 2017 @ 17:16:
[...]

Ah nou het lijkt erop dat het werkt. Wel minder dat ik nu in de mysql de data niet kan aflezen maar wanneer het eenmaal af is heb je met phpmyadmin niet zoveel meer te maken

Bedankt

Tuurlijk wel, MySQL ondersteund ook de Unix-time...

code:

SELECT from_unixtime(P_START) as starttime, from_unixtime(P_END) as endtime from poll_db;

Je moet alleen wel je * uitschrijven.