I have a big table that sometimes needs to be queried as part of the users app experience, ie:
when the user views a contact’s profile, it needs to show historical events linked to the profile
previously i added these legacy events into the app as a glide table, and the table slowed down so much i had to remove it. please can you guide me on the best way to implement? (i was thinking creating an external db to reference but perhaps big table or big query might be a better solution? i need to choose whether i stay on pro and do an external table, or, upgrade to business and use big table/big query
and if my legacy table is created as a big table… would it make sense to archive all old events to the same table - or do you suggest a different alternative for a “growing legacy/archive table”
and my last question @Darren_Murphy , what do you suggest as the next best alternative if my client doesnt have the cashflow to upgrade to $249 per month on business?
about 50k, with 20 columns. the last time it slowed my landing page down to take atleast 10seconds… but i was trying to present a graph on it… perhaps if i limit it to a list on another page other than opening page of the app it will be better?
When you say your legacy table is a “big table”, I assume you mean a very large regular table, as opposed to an actual Glide Big Table, right?
If you are switching to Big Tables, then you should keep all the data that you still need to access via the App in the same table. With Big Tables, there is no difference in performance between 100 rows and 1 million rows.
My suggestion then would be to offload/archive older data to some other place that isn’t referenced by the App.
what is the best method in your opinion to offload data to another place… do you think i would be able to automate this based on date for example if a record has a date older than 6 months export it to somewhere?
You’re currently on a Pro Plan, right?
This limits your options because you don’t have access to the queryTables call.
Just off the top of my head, an option might be:
Periodically export the whole table as CSV, and store it somewhere.
Set up an action somewhere in your App that targets and deletes the oldest row in the table that’s older than 6 months old. This can be done in such a way that it “piggy backs” on one or more other actions. So you’d essentially be crowd-sourcing the job of cleaning out old rows to your users without them being aware of it.