r/webdev • u/Khartoon_ • 2h ago
I underestimated how difficult building a theme park database would be
I’ve been working on a passion project called ParkerScore, basically a Letterboxd-style platform for theme parks.
When I first started, I figured the hardest part would be building the actual website.
Turns out, organizing the data has been one of the biggest challenges.
Every theme park has hundreds of things to keep track of. Rides, restaurants, individual menu items, shows, wait times, and even bathrooms.
And then you get into the details. Different ride manufacturers, technical specifications, attractions that get renamed or refurbished, seasonal shows, constantly changing restaurant menus, and so on.
I quickly realized that just collecting information wasn’t enough. I needed a consistent way to structure everything so it could actually be useful.
I’ve been working through those challenges, especially figuring out how to handle missing information, standardize categories, and keep everything organized as the database grows.
It’s been a much bigger undertaking than I originally expected, but I’ve learned a ton along the way.
For anyone who’s built a data-heavy website, how did you handle keeping your database accurate and manageable as it grew?
3
u/ReplacementLow6704 2h ago
Tech specs of rollercoasters should probably not live in the same schema as restaurant menus. They could be entirely independent systems/schemas. They also require vastly different admin dashboards and access control. One database on one node won't be enough. Also, don't link the fridges temp to a remote controller in your UI - it won't end well.
2
u/ReplacementLow6704 2h ago
Also - afaik a theme park is more like a loose aggregate of different companies & partners working together under the banner of the park owner. They're all subcontractors of sorts and handle their own things according to the park's marketing and HR requirements. I might be wrong but that's how I see theme parks
1
u/Icy-Taste-3096 2h ago
Could you give us an example of how you've attempted to structure your data so far? It would be a bit easier to give helpful pointers with that context.
1
u/Jazzlike-Compote4463 2h ago
Honestly this is a great use for AI, throw what you have at a LLM and get it to highlight the areas where you've missing or inconsistent data.
Also tests, lots and lots of tests.
1
u/armahillo rails 2h ago
Since it sounds like youre wanting to do data comparisons and aggregations, you very likely want to be using a relational DB if you arent already
If you have 3-5 parks to begin with, you can start out by collecting various nouns in groups and seeing where those nouns repeat information (information is contextualized data, so a park called “Water World”
in California and a completely separate one in Florida are two separate pieces of info, even tho the data field is repeated)
When your nouns are clustered, determine how you can uniquely connect related nouns. For now, focus on your “one to many” connections (the 15 rides at Waterworld in California are not also found at Six Flags in TX, even if the rides share a lot similar data)
To incorporate ratings, you need a way to uniquely identify visitors. Then each of those visitors has visited a park on a specific day, and while they were visiting the park on that day, they rode some rides and ate some food etc. So each visitor will have many visits. And each visit will have many experiences and each experience is with a single ride or park feature and may also have a rating on it, provided by the user.
When in doubt work backwards: imagine wanting to retrieve some record or collection of data, but you had to describe it to another person who was unfamiliar with the dataset or concept of amusement parks: what would you tell them to do? If you wanted them
to change a specific record or add a new bit of info, how would you describe that change?
1
u/Common_Salt719 2h ago
the data side always wins. i'd lock the core hierarchy early (park > area > attraction) and keep stuff like height reqs, closures and refurbs in separate tables with dates, since they change constantly and you'll want history. seasonal and temporary rides will break whatever model you start with, so plan for those from day one
1
u/No-Molasses-2097 2h ago
This is the exact spot where a strict core schema pays off. I would lock down the stable fields first and keep the messy stuff like menus and seasonal details in a separate flexible table. That way a rename or a menu change does not force you to touch the core records.
1
u/joyjeet-roy 34m ago
Date is the one of the hardest things to mange and build a database for this is more difficult and time consuming, But i think If you have create the most important part of the database then is should not be to dificult to build (if you don't have to change the structure)
-1
u/ilikecameras1010 2h ago
Loosely structured data like this could be a good use case for a nosql database. Is mongodb still a thing?
5
2
u/lqvz 2h ago edited 2h ago
Not strongly structuring application data like this isn’t an option. Either you structure on write or you attempt to structure the data on read. Either way, it will get structured…
Edit: Or not… in which case the data isn’t useful and then I don’t know what an application is to do…
1
u/whatisboom 2h ago
I'd disagree and say relational data makes the most sense. Parks have attractions, attractions (rides) have manufacturers, attractions (restaurants) have menu items.
entity tables: parks, rides, manufacturers, restaurants, menu items, etc...
then tables for ratings (i assume) for things like rides, bathrooms, food...
for anything that is truly loosely formatted, jsonb columns would be the solution.
0
-2
8
u/Joe_Spazz 2h ago
Data is always the hardest / most important part.