I’m trying to muster the courage to try making my first app in Bubble. I did many of the tutorials, but they didn’t cover anything about how to think about creating an app on a higher level. I got a little overwhelmed and shelfed Bubble for a few weeks, but I’m ready to try again. I’m attempting to build an app for a sponsor-a-day fundraiser that my kid’s school is doing similar to this: https://lakeharborpta.org/wp-content/uploads/2021-Sponsor-a-day-Calendar.pdf
I wanted to ask some of the more experienced developers if you’re willing to break down your app planning process on a high level. Any visuals would be amazing too!
I know wireframing would be one of the steps, but is it always the first? How do you plan for all the data structure?
Here is an example of a graphic representation of all the data I want to collect. There is prob a much better way to do it. Any feedback welcome and appreciated! Thanks.
When you plan your data structure, you just need to show each table (thing) once, you then show how the data links as a one to many, or many to many relationship (as you have done)
It looks like you have got it sussed, On the sponsors, I would store the fun raisers which the sponsors are part of also.
Thanks @nfisher ! Appreciate the feedback. I was confused about whether sponsors belong as part of a fundraiser. In an ideal world, a sponsor info could be stored outside of a fundraiser so that they could be a repeat sponsor of future fundraisers. For a newbie, it might make sense to have them as part of the fundraiser though.
Is there a proper way to depict one to many -vs- many to many in a mapping like this?
Good database design should avoid repeating data, however, sometimes its convenient, or even necessary. In think in this scenario, I would store the sponsors on the fundraiser, and also store which fundraisers that sponsor is part of on their record.