Looking for advice about how to set things up before building them out since I’ve learned that its presently impossible for a "thing” to have a field which is a “list of addresses”…
My app has booking page with inputs that allow clients provide various information using fields under the database thing, “booking”
Essentially each time the client submits a “booking", one of the most important things they must communicate is a list of addresses (delivery locations—they are actually intersections) that will serve as drop off locations for their items.
My plan is for the clients UI to show addresses they’ve added for the current booking plotted on a map as well as displayed in a repeating group where they can be viewed, deleted, and edited. (By the way, the delivery locations all need to be booked together as one delivery event).
How should I proceed?
Option 1: Try something like the ‘dummy’ approach?
Because the thing “booking” also collects other pertinent and related information like the required date, the type of delivery, etc… I’m worried that creating a new thing “delivery locations” is going to make it confusing to have the sets of addresses linked to the thing “booking” when it comes to passing the set through, searching for the set, etc…
(Side note possibly relevant for how to structure: I’ll need to create a count of the amount of delivery locations for each booking is also going to be important. I need to add a $5 for each delivery location past 8 to the total booking price.)
Option 2: Create many fields under the thing “booking” such as “delivery location 1” “delivery location 2” etc?
I’m thinking this would require creating a huge amount of fields that would probably never be used… and possibly a ton going on within the workflow. Also, if I go this route am I going to run into problems getting separate field data into a repeating group, etc?
Option 3: A really simple way of looking at this I hadn’t thought about but you’re going to point out…