Forum Discussion
MarkShnier__You
Qrew Legend
You are absolutely correct that the last thing you want to contaminate your ecosystem by binding 15 apps all together into one monster app. That basically would deny you the power and speed of using 15 different servers and let QuickBase serve you with just one server.
So one way is the somewhat painful method you described to rebuild all the relationships.
but assuming that the key field to your employees table is some kind of employee ID number which is unique or perhaps even an email address or a user ID which would be unique, then there is a Plan B.
That would be to preserve your existing employees table in this one app and bring in a connected Sync table for the global employee list. Or at least the employees for that company the app serves on the global employee list.
Then you would set up a table to table import run regularly by an Automation or Pipeline automation to copy across from the global employee list into your local employee list.
And the last thing you need to sort out if there is a possibility that an employee may be deleted from the global employee list. If that is the case then we need to make a relationship between the two employee tables and based on that relationship figure out if the employee got deleted from the global list and if so run a nightly automation or pipeline to delete those employees. But maybe old employees never die, they just become inactive.
Mark
------------------------------
Mark Shnier (YQC)
mark.shnier@gmail.com
------------------------------
So one way is the somewhat painful method you described to rebuild all the relationships.
but assuming that the key field to your employees table is some kind of employee ID number which is unique or perhaps even an email address or a user ID which would be unique, then there is a Plan B.
That would be to preserve your existing employees table in this one app and bring in a connected Sync table for the global employee list. Or at least the employees for that company the app serves on the global employee list.
Then you would set up a table to table import run regularly by an Automation or Pipeline automation to copy across from the global employee list into your local employee list.
And the last thing you need to sort out if there is a possibility that an employee may be deleted from the global employee list. If that is the case then we need to make a relationship between the two employee tables and based on that relationship figure out if the employee got deleted from the global list and if so run a nightly automation or pipeline to delete those employees. But maybe old employees never die, they just become inactive.
Mark
------------------------------
Mark Shnier (YQC)
mark.shnier@gmail.com
------------------------------
MichaelTamoush
3 years agoQrew Captain
That's sort of what I was thinking. That my app will forever be updated via table to table import or a pipeline etc, while the new app clusters can utilize a sync table. And my OCD will just deal with it until some day that I decide to make the leap and rebuild each table that moves to the global app, one by one. So that eventually my app is also synced and everything is consistent and clean.
------------------------------
Michael Tamoush
------------------------------
------------------------------
Michael Tamoush
------------------------------