Ik loop al een paar dagen tegen een probleem aan waarvan bij mij het kwartje nog niet gevallen is hoe op te lossen.
Google bood ook geen hulp.
Het gaat om het volgende:
Ik heb een table "schedules". Deze bevat in ieder geval de TIME kolommen "start" en "end". De start en end vertegenwoordigen het start en eindtijdstip van een bepaalde procedure. Werking hiervan is verder niet van belang.
Stel start is 10:00 en end is 22:00
Het tijdstip is nu 9:23. Als ik dan de query uitvoer met als filter: start<=tijdstip and end>tijdstip. Dan krijg ik zoals verwacht geen resultaat.
Is het tijdstip nu 13:14 dan krijg ik wel resultaat etc.
Dit is simpel en werkt wel. Maar ik loop tegen een probleem aan als het eindtijdstip over de nacht gaat, bijvoorbeeld: start is 22:00 en end is 02:00.
Nu werkt de filter start<=tijdstip and end>tijdstip niet meer. Want als het 23:11 is dan is start inderdaad kleiner maar hij ziet end natuurlijk ook als kleiner. Dus krijg ik geen resultaat.
Wie kan mij op weg helpen om hier toch mee om te kunnen gaan?
@Ivo P
ik begrijp dat het strikt genomen niet noodzakelijk is, maar het leek me wel verhelderend om eindtijd met starttijd te vergelijken aan beide kanten van de OR. Zeker als je zo'n statement over een jaar of wat nog eens leest. Dan is duidelijk dat je in het ene geval test op eindtijd na starttijd en in het andere geval op eindtijd voor starttijd.
Euh, dus de oplossing wordt gezocht in het relatief maken van zaken? Is het absoluut opslaan van waarden (tijdstippen, dus DATETIMEs) niet veel makkelijker?
Je moet nu ook elke keer de eindtijd uitrekenen. Als je vaak vragen krijgt als:
"Wanneer is X afgelopen?"
Dan moet je altijd antwoorden met:
"Euh, A plus B uur"
Wanneer de duur niet echt relevant is of als je deze zelden nodig hebt dan zou ik deze niet introduceren. Daarnaast is dit gegeven afleidbaar (net zoals de eindtijd afleidbaar is in de relatief opgezette oplossing). Ik zou je oplossing kiezen aan de hand van wat je vaker (rechtstreeks) gebruikt: duur of eindtijd.
Daarnaast klint het alsof er hier:
Het werken met een datum heeft niet mijn voorkeur. Als ik dagelijks op bepaalde tijden de procedure wil laten uitvoeren dan zou ik tot in eeuwigheid de tijden met datum moeten gaan vullen. Vandaar dat het een TIME veld is.
Een probleem opgelost moet worden, daar hangt nu de opzet van je database van af? Die blijkbaar niet handig in het gebruik is omdat je daar vragen over stelt.
Denk niet alleen goed na hoe je iets oplost, maar ook waar en waarom. En wat dat vervolgens voor consequenties heeft.
@Thomas
De data wordt vanaf extern geladen in de database. Hier kan ik niets aan veranderen. Ja er zijn meerdere wegen die naar rome leiden. Maar in dit geval is de snelste als ik het rechtstreeks uit de database kan halen.
@Jan Thanks. Dit werkt helemaal... Als ik hem zo bekijk had ik het eigenlijk zelf ook wel kunnen bedenken... Maar bedankt!
De database is voor jou dus readonly en je kunt deze niet structureel aanpassen?
Dit lijkt mij een bepalende factor bij het opstellen van een oplossing.
Je zegt hier enkel over:
Werking hiervan is verder niet van belang.
Ik denk dat zojuist het tegendeel is bewezen?
Oplossingen worden aangedragen op grond van aangeleverde informatie. Als niet voldoende informatie wordt aangeleverd kan ook geen fatsoenlijke oplossing worden voorgesteld.
@Thomas
De database kan ik wel degelijk aanpassen. Maar ik zou in dit geval niet weten waarom. De geladen data is alleen een tijdsstempel en staat compleet los van een datum. Die input kan gewijzigd worden maar zal niets meer opleveren gezien alle benodigde data geladen wordt.
Ik ben er verder al uit.
Ik ben het wel met je eens dat je vaker wat verder moet kijken wat nu eigenlijk de oplossing is ;)
