Thanks for your responses.
I will take a look at those webinars, although I do feel like I have a fairly good grasp of relationships in quickbase - their strengths in terms of pulling lookup fields into the child, and their limitations.
Particularly that you can only join on a single field that is designated as a key field - which must then be generated as a surrogate id.
Unfortunately, there is no ability to define multiple natural keys as alternate composite keys and join tables via those as well.
If that capability were added, a multitude of these types of design obstacles would be resolved!
Just a trade-of of using quickbase for its great rapid UI/overall solution generation vs using a more "real" database that would requiring more coding, but gives far more flexibility in modeling the data.
I have looked at automations and used them for some other simpler areas of smaller reference tables that are very slowly changing or added.
The problem/ limitation with automations is that the triggering actions only work on the first record of the action in the triggering data set. For instance, if you are adding multiple records at once via an import, the "add" triggering action(s) will only be run on the first record that is added. This makes them work for UI type interactions , but not for tables where bulk operations may occur more frequently.
I want to implement a clean solution that is at the core of the data modeling/management so it occurs each and every time the data is manipulated - from any avenue of manipulation. Otherwise, there are bound to be maintenance issues that can consume many hours.
I am a developer. So, I am also researching the various quickbase API calls that can be applied. There are some good youtube tutorials I have found illustrating solutions using the API for similar (although not identical) design situations.
MCP
