Best practice Ticket applicatie

[Alain]

Ben op zoek naar de beste manier om een ticket applicatie (plaatsen voor een event) te ontwikkelen. Meest logische manier lijkt me een tabel met de voorstellingdata te linken aan een tabel met alle plaatsen (keyfield datum voorstelling). Helaas kan ik dit niet in een portal doen want elke plaats moet ook visueel met status (verkocht/beschikbaar) op het zaalplan getoond worden in filemaker. Elke plaats moet dus in een aparte relatie.

 

Geen probleem, maar het gaat wel over 1000 plaatsen, dus ook 1000 relaties. Ik heb ondertussen alles op die manier uitgewerkt en alles werkt zoals het hoort. Maar ik stel wel vast dat het opstarten erg traag gaat, het bestand is ook al 70 MB groot terwijl er eigenlijk bijna geen data inzit. OOk het aanpassen van de velden gaat heel erg traag (rebuilding depencies). De applicatie zelf gaat wel erg vlot op dit moment en ik merk geen enkele vertraging in het aanklikken van de plaatsen. Maar ik vrees dat wanneer er meer data en meer users gebruik maken het geheel misschien onwerkbaar wordt.

 

Vandaar mijn vraag: zouden jullie het ook op die manier aanpakken of ben ik wel heel omslachtig bezig. Ik hoor het graag. Alvast bedankt!

[Ari]

Ik denk dat je beter wat ondersteuning kan zoeken bij iemand die weet hoe je een 'genormaliseerd' datamodel moet opzetten voordat je gaat experimenteren.

[dudematters]

Hoe heb je het opgezet? Met zware graphics? Want 70MB voor een lege applicatie is wel erg heftig.

 

Werk je vanuit relaties en koppel je daaraan de plaatsen, of werk je vanuit plaatsen en koppel je daaraan een relatie? Want dat is ook nogal een verschil. 1000 plaatsen en 1000 relaties zou qua snelheid geen enkel probleem moeten zijn. Mijn databases worden pas traag als ik richting een miljoen ga....

[Alain]

ari: en wat mag een "genormaliseerd" datamodel dan wel zijn? Elke database is anders en dit lijkt me net een plek om dit soort dingen aan te kaarten tenzij ik me vergis. En nog wat minder wat er fout is met experimenteren. Op die manier gebeuren de mooiste nieuwe ontdekkingen.

@dudematters: Bedankt! Van zodra de relaties werden aangemaakt (iets wat ik heb geautomatiseerd uiteraard) zag ik de omvang erg snel stijgen. Geen zware graphics. Zaalplannen zijn geïmplementeerd maar dat gaat over een paar png bestanden van 300 Kb. 1 miljoen records bedoel je wellicht. Dat is inderdaad geen probleem. 1000 relaties is nog iets anders. Je vraag hoe ik werk begrijp ik niet helemaal. Alvast bedankt!

[fmwebshop]

Alain

 

Het lijkt me hoogst onwaarschijnlijk dat je 1000 relaties nodig hebt in een toepassing.

Na het lezen van je post zou ik me zelfs kunnen voorstellen dat je dit specifieke probleem af kunt met een klein aantal relaties.

Ik denk dat Ari je een verstandig advies heeft gegeven:

Laat er even iemand naar kijken die ruime ervaring heeft in het opzetten van databases, dat gaat je mogelijk een hoop werk en ellende besparen.

 

 

Vr gr

Harry

[Alain]

Als je één relatie nodig hebt per plaats. Heb je 1000 relaties nodig als er 1000 plaatsen zijn. Dat kan niet anders. Vraag is of je met dit soort relaties moet werken. Omwille van de weergave zit je vast aan deze weergave. Het is uiteraard ook mogelijk om in de tabel voorstellingen meteen ook de plaatsen te integreren maar dat is wel een erg clumsy manier om het te doen. Ik heb de afgelopen jaren ongeveer 100 applicaties gemaakt met de meest exotische databaseconnecties. Ik had trouwens al bij een paar professionele developers gepolst maar die zouden het op dezelfde manier doen. Vandaar dat ik hier mijn licht eens opsteek.

[Ari]

ari: en wat mag een "genormaliseerd" datamodel dan wel zijn?

 

Je vraag zegt denkt ik genoeg. Een degelijke applicatie bouwen is (ook in Filemaker) nou eenmaal wat anders dan een taart bakken.

 

Als je googelt op 'database normaliseren' kom je genoeg informatie tegen. Hebben die 'professionele' developers overigens nog nooit gehoord van een tussentabel?

 

Succes

Edited March 7, 2011 by Guest

[fmwebshop]

Tsja...

 

 

Lees dit aub VOOR de bovenstaande reactie van Ari

[Alain]

Ik heb ervaring met tussentabellen en uiteraard ook de mensen die ik reeds heb gevraagd. Die techniek is inderdaad af en toe verdomd handig om dingen te vereenvoudigen. Maar als je deze situatie even bekijkt zou je weten dat het je geen stap vooruit helpt. Bij elke plaats hoort immers slechts één voorstelling. Een tussentabel zorgt dus voor een onnodige extra stap.

[andries]

He Alain,

 

Je kan ook gebruik maken van Portal Filters als je niet telkens je relatie wil herhalen. Op die manier kan je steeds naar de "plaats" tabel gaan kijken, en via de portal filter enkel de record van die plaats tonen. Portal filters zijn nieuw sinds FM11, dus check wel met je eindgebruikers of ze deze versie gebruiken.

 

Zo heb ik bijna exact hetzelfde eens gemaakt voor een evenementen bedrijf, die personen aan tafels wouden toekennen. Eén relatie van evenement -> zitplaatsen, en dan met portal filters de juiste records op de juiste plek op de layout laten verschijnen.

 

Ook voor hun was het makkelijk want moest hen enkel uitleggen hoe portal filters werkte, nadien konden ze zelf nieuwe evenementen aanmaken en de layout per evenement schikken zoals ze wouden.

[Alain]

Dat is een interessante piste Andries, zoek ik meteen uit. Heb ondertussen ook een andere mogelijkheid: het aantal plaatsen dat wordt getoond op het scherm beperken tot pakweg 300 plaatsen. Je hebt immers slechts evenveel relaties nodig als je plaatsen simultaan op het scherm wil tonen. Het is een tussenstap want de gebruiker moet een keuze maken uit de verschillende zones in de zaal maar het beperkt wel het aantal relaties... Bedankt!

[Alain]

Portal filtering is inderdaad de beste oplossing voor dit probleem. Heel erg bedankt Andries!

[fmwebshop]

Kun je hier niets mee?

 

Vr gr

Harry

Naamloos.fp7

[Alain]

Hé bedankt Harry. Herhalingsveld is inderdaad een mogelijkheid. Probleem met deze oplossing is:

- Je moet rechte rijen hebben. Het gaat over een zaal met tafeltjes en elke plaats aan de tafel moet aanklikbaar zijn. Met deze oplossing wordt het zaalplan al snel een abstracte voorstelling die niet onmiddellijk overeenkomt met de realiteit.

- Exporteren is een probleem. Voor dit soort applicaties is een export naar excel voor diverse doeleinden een must. Met een herhalingsveld kan je alleen de eerste waarde exporteren. Om die reden gebruik ik zelf noit herhalingsvelden wanneer het veld voor export in aanmerking kan komen.

- Er zijn verschillende prijscategorieën. De ene stoel is duurder dan de andere. Dat in deze oplossing implementeren is redelijk omslachtig.

- Zoekopdrachten zoals hoeveel plaatsen zijn er nog in categorie x over alle voorstellingen heen worden bijzonder omslachtig.

 

De filter op een portal is een uitstekende oplossing voor dit probleem maar helaas is het dus pas mogelijk vanaf FM 11. Voor oudere versies is de enige oplossing om voor elke plaats een aparte relatie aan te maken en dat is niet optimaal... Bedankt voor het denkwerk en het bestand!

[JeanWM]

Als je één relatie nodig hebt per plaats. Heb je 1000 relaties nodig als er 1000 plaatsen zijn. Dat kan niet anders.

 

Eigenaardige redenering.

 

Wij hebben een box office programma lopen voor een stadium met 16500+ plaatsen.

 

Het geheel loopt met 3 relaties.

Ticket verkoop, plaatstoewijzing, reservering.

Ieder deel kan in portals getoond worden, zoek functies op verschillende, door de gebruiker in te stellen argumenten.

Rapporten kunnen geprint worden, toegangslijsten algemeen en per ingangspoort, aanwezigheidslijsten voor de brandweer en andere hulpdiensten....

 

Ieder block van het stadium kan weergegeven worden om of plaatsen aan te klikken of om verkochte plaatsen te markeren vanuit de ticket verkoop.

 

Ari heeft gelijk. Het ruikt naar een gigantische niet genormaliseerde design flaw.

 

En als toemaatje: het voornoemde stadium heeft onlangs een uitbreiding gehad tot 21050 plaatsen,

Het zou helemaal gek zijn moesten we 4550 relaties moeten bijmaken om dat op te vangen.

 

Een looping script met een variable was voldoende voor de update.

 

Het nieuwe stadium zal 28500 plaatsen hebben. Het programma is al af ( en niet met 28500 relaties), het stadium nog niet...

[Rony Rabijns]

Het programma is al af, het stadium nog niet...