[PHP] Prijsvraag datum herkennen

[Verwijderd]

Beste mede-tweakers,

Ik ben op het moment bezig met een prijsvraag systeem. Er is bijvoorbeeld een website "www.test.nl" die een prijsvraag heeft. Die website heeft een aantal edities. Je kunt dus elke maand een andere prijsvraag hebben. Het probleem nu is , hoe kom ik er achter welke prijsvraag ik op welk moment moet opvragen?

Dit is de structuur van de tabel waarin de edities staan:

CREATE TABLE `ceditions` (
`id` smallint(5) unsigned NOT NULL auto_increment,
`contest` smallint(5) unsigned NOT NULL default '0',
`date` date NOT NULL default '0000-00-00',
`title` varchar(100) NOT NULL default '',
PRIMARY KEY (`id`)
)

Zoals je ziet sla ik er dus ook een datum in op. (logisch). Als ik bijvoorbeeld in de database een editie heb op 2004-22-05 en een editie op 2004-29-05 en ik bezoek op 24-05-2004 de webpagina. Hoe kan ik de code laten weten dat op dat moment 2004-22-05 op de pagina weergegeven moet worden?

Alvast bedankt,

Michel

[gorgi_19]

Waarom doe je geen start- en einddatum? Zo bouw je gelijk een stuk flexibiliteit in die wel te verwachten is en los je gelijk dit probleem op.
En anders kan je wel vergelijken met een DateDiff-functie oid; indien het verschil kleiner dan 7 is, dan is de prijsvraag in de huidige week.

[ Voor 34% gewijzigd door gorgi_19 op 22-05-2004 16:18 ]

[Verwijderd]

En anders kan je wel vergelijken met een DateDiff-functie oid; indien het verschil kleiner dan 7 is, dan is de prijsvraag in de huidige week.

Het punt is dat er geen vaste tijd zit tussen een editie. Het kan dus de ene keer per week, per maand, per 2 weken zijn en de andere keer weer anders.

[gorgi_19]

Verwijderd schreef op 22 mei 2004 @ 16:20:
[...]


Het punt is dat er geen vaste tijd zit tussen een editie. Het kan dus de ene keer per week, per maand, per 2 weken zijn en de andere keer weer anders.

Dan geldt het eerste gedeelte van m'n post..

[Gomez12]

select max (datum) where datum < huidige datum???

Beetje kromme constructie die niet helemaal lekker werkt met een beetje grootte dbase. Maar voor kleine dingen volstaat dit.
Edit: Zoals soultaker dus volledig zegt

[ Voor 13% gewijzigd door Gomez12 op 22-05-2004 16:40 ]

[Soultaker]

De 'datum' is dus een begindatum. Je zoekt dan dus de laatste prijsvraag die in de database staat, behalve natuurlijk als de begindatum daarvan nog 'in de toekomst' ligt. Het lijkt me dat je dan zoiets krijgt:

SQL:

SELECT FROM ceditions
WHERE date < NOW()   -- alleen edities die al begonnen zijn meenemen
ORDER BY date DESC   -- ordenen; meest recente editie eerst
LIMIT 1              -- neem er eentje; de meest recente dus.

[ Voor 6% gewijzigd door Soultaker op 22-05-2004 16:39 ]

[Verwijderd]

Zoals * gorgi_19 zegt, met een begin- en einddatum werken.

[gorgi_19]

Gomez12 schreef op 22 mei 2004 @ 16:37:
select max (datum) where datum < huidige datum???

Beetje kromme constructie die niet helemaal lekker werkt met een beetje grootte dbase. Maar voor kleine dingen volstaat dit.

Een index op het datumveld leggen moet dan een hoop schelen, denk ik.

[Verwijderd]

Bedankt allemaal! ik ga er morgen weer even aan sleutelen, nu richting huis.

[Gomez12]

gorgi_19 schreef op 22 mei 2004 @ 16:39:
[...]

Een index op het datumveld leggen moet dan een hoop schelen, denk ik.

Waarschijnlijk wel, maar ik hou er niet van om een aggegrate (<=90% spelfout) functie te gebruiken voor zo'n doel als dit.

Vind ik altijd een beetje moeilijk toepasbaar in een iets grotere query waar ik mijn group by op heel andere dingen wil leggen.

Plus dat ik over het algemeen (=bijna nooit) alleen een date opsla. Als ik een datum opsla wil ik "altijd" een tijd erbij hebben. Plus dat ik het een overbodige index vind voor dit soort dingen.
Oftewel gewoon een begin en einddatum laten invullen

Desnoods bij het invullen van een nieuwe actie de einddatum vullen op 01-01-2010 en bij de vorige actie de einddatum veranderen naar 1 dag voor de nieuwe actie.

[gorgi_19]

Gomez12 schreef op 22 mei 2004 @ 16:48:
Waarschijnlijk wel, maar ik hou er niet van om een aggegrate (<=90% spelfout) functie te gebruiken voor zo'n doel als dit.

Vind ik altijd een beetje moeilijk toepasbaar in een iets grotere query waar ik mijn group by op heel andere dingen wil leggen.

Plus dat ik over het algemeen (=bijna nooit) alleen een date opsla. Als ik een datum opsla wil ik "altijd" een tijd erbij hebben. Plus dat ik het een overbodige index vind voor dit soort dingen.
Oftewel gewoon een begin en einddatum laten invullen

Desnoods bij het invullen van een nieuwe actie de einddatum vullen op 01-01-2010 en bij de vorige actie de einddatum veranderen naar 1 dag voor de nieuwe actie.

Die aggregate functie kan je omzeilen door de methodiek te gebruiken van Soultaker. Sowieso ben ik ook voor om een begin- en einddatum te gebruiken; je kan dan ook meerdere prijsvragen (of geen prijsvragen), betere planningsmogelijkheden, etc.

Verder kan je een datum + tijd opslaan, geen probleem lijkt me? Als ik me goed herinner, wordt een datum opgeslagen met als bijbehorende tijd 0:00:00.

[Johnny]

Zelfs als je iedere dag een nieuwe prijsvraag hebt dan heb je na 3 jaar net iets meer dan 1000 records, over de grootte zou ik me dus niet zoveel zorgen maken.

Trouwens, als een einddatum onbekend is vind ik het mooier om gewoon NULL te gebruiken in plaats van een datum die nog heel ver weg is. Waar is ie anders voor?

[gorgi_19]

Johnny schreef op 22 mei 2004 @ 17:01:
Trouwens, als een einddatum onbekend is vind ik het mooier om gewoon NULL te gebruiken in plaats van een datum die nog heel ver weg is. Waar is ie anders voor?

Werkt een Between statement dan ook nog?