You create another DB “address”
Have two field: type and address.
In your contacts app, have a field of type “address” that point to the new DB created.
I don’t know if I am saying the same things mentioned but differently or not.
I would create a data type called “address type” with data fields like name ( for example “home or work”…could go further and add things like home 2 etc )
Then in your data type of “address” have a data field relating to the “address type” data type…also might want to have a data field that relates to the “contact” data type as well.
Then in your “contact” data type have a data field that is a list of address that is related to the data type “address”.
On “user” data type have a data field that is a list of “contacts”
Then you can show a repeating group with datasource of “current users list of contacts”. Could have a imbedded r.g. with datasource of “current cells contacts list of address” and in each cell display the address and the type.
I wish when saving a list of things you could save a list as well.
Like
123 Main St, home, 0 (round trip miles)
456 Ave, work, 5
Or, like what I’m needing to do with my project rates
$900.00, session
$2000.00, usage
I Kida feel like it’s not as efficient to have a whole separate DT when I just need to save one or two attributes. Because just to keep all the data straight I would need to reference the contact in the address DT but then its all doubled up.
But I suppose with the linking it’s not the worst solution.
I have come to overuse the the ability to relate data types just for ease of data manipulation and display. Probably not the best practice but I find it makes things easier for me for now, but later it may prove to make maintenance more difficult.
Having the double up as you mention below:
That isn’t necessary…I said you might want to have it as well, like it is supplemental. Like I mentioned, I use the relations between data types probably too much as it makes things a bit easier to do various searches etc.
So for example, having the “contact” as an optional related data field on the “address” just means you could search for all addresses and see which contact they belong to…which implies more than one address would have the same contact shown…this way if you don’t want to ship something to them multiple times, you could choose the most appropriate address to ship to.
If you don’t use the optional “contact” on the “address” data type, you still have the ability to search your “contact” data type for their list of “addresses”. However, if you don’t use it and “double it up” you wouldn’t be able to search addresses and see which contact it belongs to.
I can’t find how to create a list of things
But you could do a recursive api workflow to create a list of things based on a number…then I think you could just have the thing that a list of is being created for have a data field that is a list of other things of any type such as text or related to another data type.
Your examples:
That is not a list of things that has a list of things…it is a list of things with two data fields ( price and type (as a name) )
What is your current database structure and the workflows for trying to save the list of project rates with the price and type?
