Ik wil een query en dus een tabel waarbij de begin en eindtijd van het event wordt berekend.
ID| event |Duur | begin | Einde | plaats
-------------------------------------------------
1 | U2 | 30 min | 13:00 | 13:30 | stage 1
2 | Coldplay | 40 min | 13:30 | 14:10 | stage 2
De eerste begintijd staat vast 13:00 uur, de rest kan berekend worden door de begintijd te pakken + de duur = eindtijd = gelijk de begintijd van het volgende event.
De bedoeling is dat als je bij een van de events (stuk of 20) de duur verandert het gehele tijdsschema wordt aan gepast.
$eindtijd = date("h:i",$vastestarttijd); // of tijd uit de DB,...
//Je resultaten overlopen in een foreach
foreach ($arr as &$value) {
// je gegevens tonen op je website
//Berekenen van de eindtijd/begintijd
$nieuwebegintijd = $eindtijd;
$duur = 30; //vervangen door je duur uit je DB
$nieuweindtijd = date("H:i", strtotime($begintijd)+($duur*60)); //*60 om om te zetten naar minuten
//eindtijd opslaan buiten de for-lus om straks opnieuw te gebruiken
$eindtijd = $nieuweeindtijd;
}
$eindtijd=date("h:i",$vastestarttijd);// of tijd uit de DB,...
//Je resultaten overlopen in een foreach
foreach($arras&$value){
// je gegevens tonen op je website
//Berekenen van de eindtijd/begintijd
$nieuwebegintijd=$eindtijd;
$duur=30;//vervangen door je duur uit je DB
$nieuweindtijd=date("H:i",strtotime($begintijd)+($duur*60));//*60 om om te zetten naar minuten
//eindtijd opslaan buiten de for-lus om straks opnieuw te gebruiken
$eindtijd=$nieuweeindtijd;
}
Als je het toch wilt opslaan in de database, dan doe je net hetzelfde, maar met een update die alle ids overloopt en de begin- en eindtijd opnieuw overloopt..
EDIT: Het is het idee, is nu uit de losse pols hier neergetypt.
Begin en einde overlappen dus nooit, ondank het feit dat de (fictieve?) concerten op verschillende stages (podia?) plaatsvinden? Ben je een timetable aan het maken voor een soort van festival of iets dergelijks? Is dit je huiswerk? Wat probeer je te bereiken?
Het begin en einde staan niet echt vast denk ik, maar hangen af van (worden berekend met behulp van) een starttijd en een duur. De berekende gegevens (begintijd, eindtijd) zijn dus min of meer redundant (dubbel). Ze zijn af te leiden uit starttijd, duur en ... volgorde. Dit veld ontbreekt nog? Of worden de gegevens altijd direct in de goede volgorde ingevoerd?
Meestal is het handig om een aparte kolom (naast je primary key) aan te maken als een volgorde relevant is. Dit lijkt mij in jouw geval van toepassing. Immers, als de duur van een optreden verandert, verschuiven alle begin- en eindtijden van optredens die hierna komen. Je hoeft niet alles opnieuw te berekenen... En hoe/waar je dat precies opslaat... tja, dat kan op tig verschillende manieren en hangt een beetje af van wat je probeert te bereiken.
En als je dus verschillende podia hebt, heb je waarschijnlijk ook meerdere "tijdlijnen"? Op muziekfestivals staat band B in tent 2 ook niet te wachten op band A die in tent 1 optreedt hoor, verschillende optredens vinden doorgaans tegelijkertijd plaats en moet je dus kiezen welke je wilt zien .
Het is geen huiswerk maar een soort tool om het plannen van ons festival makkelijker te maken.
Het staat vast dat het om 13:00 uur begint.
De volgorde is ook relevant maar kan gewoon als ID worden genoteerd omdat eigenlijk alleen de duur , de band en het podium de enige variabele zijn.
Het doel is, om te spelen met de volgorde van de verschillende bands, en de duur van een optreden.
Wat er dus aangepast kan worden, duur , welk podium, welke band.
De bands haal ik uit een andere database maar dat lukt allemaal wel.
De vraag was, hoe programeer ik de query en vervolgens de rekensom om elke keer de begintijd uit te rekenen.
Als er een optreden klaar is op bv podium 1, gaan we gelijk verder met podium 2, er speelt niets tegelijkertijd. (nog niet, wellicht over een jaar of 5)
Ik kan dit wel in excel maken maar dan is het niet voor de hele groep toegankelijk en via deze weg wel.
Iemand die mij een min of meer complete code aanlevert kan rekenen op twee vrijkaarten
Thomas - 12/12/2014 13:28 (laatste wijziging 12/12/2014 13:30)
Moderator
Maar wat is "podium" in dat geval dan? Is dit echt een fysieke locatie waar artiesten op staan? Zijn "podium 1" en "podium 2" echt twee verschillende geografische locaties? Als dit het geval is, en toeschouwers vervolgens moeten verhuizen, dan wil je toch ook een soort van pauze tussendoor inlassen? EDIT: en wat dacht je van het klaarzetten van instrumenten, belichting etc? Zit dit in jouw definitie van "optreden" ingebakken?
Waar je ook voor kunt kiezen is een soort van tijdsblokkenstructuur. Elk blok duurt bijvoorbeeld een half uur. Voor een optreden van 40 minuten zou je dan twee blokken kunnen reserveren. Ook kun je op die manier rekening houden met vertraging/uitloop (encores?). Het probleem is een beetje: als dingen precies passen, zijn ze meestal te krap .
Zoals met een heleboel zaken: jouw probleem is niet uniek. Je zou eens kunnen kijken hoe andere festivals dit aanpakken?
Verder zeg je:
Citaat:
Het staat vast dat het om 13:00 uur begint.
Als je nog zoekende bent naar een vorm is het misschien beter om dingen zo flexibel mogelijk te houden en (nog) niet vast te pinnen. Wat misschien een idee is, is een instelbare starttijd?
Citaat:
Het doel is, om te spelen met de volgorde van de verschillende bands, en de duur van een optreden.
Dit lijkt mij reden te meer om optredens te voorzien van een volgorde? Daarmee kun je dan via een interface optredens verwisselen / verschuiven?
Citaat:
Als er een optreden klaar is op bv podium 1, gaan we gelijk verder met podium 2, er speelt niets tegelijkertijd. (nog niet, wellicht over een jaar of 5)
Misschien wil je daar dan nu al rekening mee houden in je ontwerp, anders mag je straks weer een hoop zaken opnieuw doen. En als dit dan vervangen gaat worden door een groter systeem, dan is je bestaande systeem al een (betere) specificatie hiervoor (dan de variant die hier geen rekening mee hield).
Bij wijze van gedachtenexperiment: verplaats je eens in een bezoeker, deze heeft waarschijnlijk zijn/haar favoriete artiesten die hij/zij wil zien. Waar loopt deze bezoeker tegenaan bij jouw programmering?
De podiums staan overigs naast elkaar dus je hoeft helemaal niets te missen.
"Dit lijkt mij reden te meer om optredens te voorzien van een volgorde? Daarmee kun je dan via een interface optredens verwisselen / verschuiven?"
Het gaat er meer om dat we een blokkenschema creeren met een vaste volgorde
optreden 1 op hoofdpodium (1) van ** band dat xx minuten duurt
pauze op (2) dat xx minuten duurt
optreden 2 op kleine podium (3) ** band dat xx minuten duurt
pauze op (2) dat xx minuten duurt
optreden 3 op hoofdpodium(1) ** band dat xx minuten duurt
etc etc
Een variabele begintijd zou kunnen maar in de vergunning staat al vast dat we om 13:00 uur beginnen.
Op dit moment zijn we bezig met prijs en beschikbaarheid van bands. Als we deze weten en we hebben ze geboekt kunnen we een bepaalde band aan een blok toewijzen.
Om dus te kunnen zien hoe we zitten met onze timeline en waar we moeten of kunnen besparen in tijd.
Het schuiven met bands kan ik makkelijker doen door in een "blok" een andere band in te vullen dan dat ik de volgorde verander.
Over het organiseren hoef je me niet wijzer te maken dat lukt allemaal wel. Dit is mijn zevende editie. :-)
Op dit moment heb je één tijdslijn waarin evenementen zitten.
Een evenement heeft een duur (in een tijdseenheid, bijvoorbeeld minuten), een type (optreden, pauze) en een locatie (podium X, podium Y, etc.). Indien het een optreden betreft, zou je hier nog extra informatie aan kunnen hangen (band, eventueel op te voeren acts etc.).
Maar als je gaat schuiven met deze blokken (wat me nog steeds een stuk eenvoudiger lijkt dan zaken opnieuw invullen) dan kan het dus gebeuren dat je ineens twee opeenvolgende pauzes hebt ofzo . Of een pauze aan het einde.
Mocht het festival groter worden krijg je waarschijnlijk per locatie een eigen tijdslijn waarbij meerdere evenementen tegelijkertijd (parallel) plaatsvinden, maar nu dus nog niet. Deze tijdslijn is niets meer dan de volgorde (per locatie) van evenementen (op die locatie). In jouw geval kun je het (voor nu, in ieder geval) beter omdraaien: je begint met het creëren van een (één) tijdslijn waar je evenementen aan toevoegt.
Het berekenen van begin- en eindtijd is wat mij betreft "secundair", dit wordt bepaald naar aanleiding van de volgorde. Ik weet ook niet of het echt meerwaarde heeft om dit expliciet op te slaan. Je kunt dit immers makkelijk berekenen als je deze informatie weergeeft. Daarnaast veranderen deze tijden continu zolang je schuift met de volgorde. Als je de begin- en eindtijden expliciet wilt opslaan zul je hier code+queries voor moeten schrijven. Dit maakt je applicatie mogelijk complexer dan strict noodzakelijk. Wat is er op tegen om enkel met begin- en eindtijden te werken in de weergave? Je hoeft dan alleen wat extra code (niets eens extra queries) te schrijven voor het uitrekenen van tijdstippen.
Ik denk dat het helpt als je een soort van plaatje maakt (een visuele voorstelling) van wat je wilt doen. Je interface (beheerpagina) zal dus een soort van balk met blokjes zijn die je kunt toevoegen, verschuiven en verwijderen. (Of meerdere balken, als je meerdere tijdslijnen hebt). Dit maakt het indelen veel intuïtiever denk ik. Deze weergave is dan ook direct je festival-programma. Heb je bijvoorbeeld al eens gekeken naar de sortable plugin van jQuery (bekijk ook vooral de verschillende voorbeelden in de rechterkolom)? Daarmee kun je elementen in een of meerdere lijsten draggen en droppen.
(rest van de jQuery en opmaak komt van het internet)
Je kunt blokken verslepen tussen de grijze kolommen.
Je kunt blokken toevoegen via de invoervelden (time = tijd in minuten = hoogte blok in pixels).
Je kunt blokken verwijderen door deze in de rode kolom te droppen.
Dit voorbeeld slaat verder geen data op, maar illustreert (mogelijk) goed wat er allemaal kan met jQuery en hoe handig een visuele interface (mogelijk) is.
Het bleek nogal lastig om kolommen te "synchroniseren" en "mutual exclusive" te maken (je moet dan allemaal dummy-items invoegen in de overige kolommen). Dat mag je zelf uitzoeken .
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.