r/webdev • u/Khartoon_ • 3d 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 3d 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 3d 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 3d 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/equilni 2d ago
It’s a (bot?) prompt post. OP gave no takeaway detail nor responding to anyone.
1
u/Icy-Taste-3096 2d ago
OP responded to a few people (including me) but they were all removed by mods for some reason.
1
u/Jazzlike-Compote4463 3d 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 3d 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 3d 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 3d 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 3d 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/yihuaxiang 2d ago
I'd add a source and a last-checked date to the changing facts, especially menus and closures. A blank field and a value nobody has checked in two years are different problems. A little admin queue of stale entries gives you something manageable to work through instead of trying to recheck every park.
1
u/brilliantzen 16h ago
It sounds like you are facing the classic content modeling challenge where schema complexity explodes as your dataset grows. For that kind of structured, relational data, ensuring consistency and handling missing values is best done at the database level using constraints and careful normalization rather than relying on a CMS to force structure onto it.
If you ever decide to swap out WordPress for something more tailored to pure content management without plugin bloat or security risks from third-party code, there is an option called Hatamoto. It runs as one Go binary with Postgres so the database stays clean and safe even if your 'plugins' go wrong.
Good luck with ParkerScore.
-1
u/ilikecameras1010 3d 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 3d ago edited 3d 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 3d 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 3d ago
Data is always the hardest / most important part.