Need help with setting up the structure of the database backend.
Below is the use case:
A neighborhood has multiple Apartments (names).
An apartment has multiple unique apartment number.
So for example:
Neighborhood N1 has Apartments A1 and A2.
A1 has 2 unique apartment number like 101, 102
A2 has 4 unique apartment number like 101, 102, 103, 104
I want my users to choose a Neighborhood, then the Apartment Name (A1 or A2) and finally the Apartment number they are interested in.
The options to choose for Apartment names should be dependent upon the Neighborhood chosen. Also the options to choose for Apartment number should be based on what is chosen in Apartment Name.
Hence if the user chose:
Neighborhood - N1 then he should see only 2 options for
Apartment Name (A1 and A2).
Next if he chooses A1, they should only be able to select options 101 or 102.
There can be 100’s of neighborhoods in a city and that in turn can have 100s of aparments, each with its unique apartment numbering system.
How can i set this up? Any suggestions are greatly appreciated.
You can use option sets for this and use a relation data field to ‘link’ the Apartments to a particular Neighbourhood.
But, my question is do you need users to set create their own Apartment Names or Neighbourhoods, or will they already be set?
If so, you won’t want to use Option sets as users can’t create their own in your bubble app’s UI (at least not the last time I checked). If that’s the case, you are better of using Data Types and linking them together.
Datatypes in bold, fields in regular text, field type in paranthesis. Of course this will need to be modified further:
Neighborhood
Name (text)
Notes (text)
Entrance Address (geographic location)
Building (What you are calling Apartment)
Name (text)
Neighborhood (Neighborhood)
Address (geographic location)
Apartment (A single Apartment part of a Building)
Name (text)
Building (Building)
Status (Option set: Apartment Status)
Make an option set: Apartment Status
Options: Available, Taken, Temporarily Closed, Closed (Idk might need to add some more)
Might need an Option set for Building so it can have a status field, and probably Neighborhood too. If a Neighborhood gets paved over you want to be able to mark it as “Closed” instead of deleting it,
My guess is you would want another text field under Building for a “prefix” so you can autogenerate a sequential number for each Apartment, and put the building prefix “A” in front of it.
And if you want to go further and start tracking tenants, that would be either a new datatype or the User datatype stored under the apartment.
To answer your question and also using the terminology as above:
These are fixed sets and the user will not be able to modify them.
The user will just choose their Neighborhood, Building and Apartment Number when signing up. Its a predefined option/data set.
I plan to take the DataType route so can internally store these in tabular format.
Option sets will not work in this use case because each building can have varied number of apartments and the apartment number (identifier) can vary.
Yea do datatype because even if it was a set amount of apartments, good luck manually typing each one instead of importing a CSV or something. And if you add one apartment now you have to push your app to live and users need to refresh.
