Glide Big Tables – Better than Glide (Regular) Tables?

General
1

I see that the option to choose a glide table when choosing a data source is no longer there. But glide Big Tables is on offer. I assume glide tables are the default and big tables is where things are headed.
Can anyone give some clarity on the capabilities of big tables. Is it at least capable of doing what glide tables can do, can we use computed columns with big tables.
Any updates would be appreciated.

2

Here a thread that you read:

Limitations of Big Tables

There are some features in Glide that aren’t compatible with a Big Table. These unavailable features are:

  • Some Single Value columns that target Big Table columns.
  • Multi Lookups into Big Tables (eg. Lookups via Multiple Relations or Lookups that target an entire Big Table column)
  • Rollups are supported on Math, Template, and IfThenElse columns only, and only if those columns target basic columns.
  • The Delete Rows action cannot be applied through a multi-relation in Big Tables.
  • A Big Table cannot be the User Profile data source.
  • Computed columns are limited to 100 rows.
  • Computed columns cannot be used as filters in a Big Table.
1 Like
3

I realise that list is lifted directly from the docs, but the docs are somewhat out of date, and some of those points are quite misleading. Specifically:

A Single Value column that directly targets a Big Table will not work. But a Single Value column that targets a Big Table via a Multiple Relation or Query will work. However, only Single Value->First is supported.

Lookups via Multiple Relations and Queries are supported, but limited to the first 100 matching rows.

Rollups (and Joined Lists) are actually supported for most computed column types, but limited to the first 100 matching rows. For example, a Joined List of a JavaScript column will work perfectly fine.

This is misleading. It gives the impression that computed columns will only be calculated for the first 100 rows, which is of course incorrect. Where the 100 row limit comes into play is when you try to aggregate computed columns, eg. via Rollups or Joined Lists (see my comments above).

NB. All of the above assumes that the “More computed column support for Big Tables” preview feature is enabled.

6 Likes
4

Thanks for this, this helps a lot👍

1 Like
5

I had a short and eye-opening talk with @tuzin.arts today about Glide Big Table. I’ll rephrase what I understood (my apologies, Art, if I misunderstood anything):

  1. By default he will build on Glide Big Tables and not on Glide (Regular) Tables
  2. If a table will expand in terms of number of rows, even if it’s a few rows every so often, he will use a Glide Big Table
  3. He will only use a Glide (Regular) Table for helper tables which have a fixed number of rows
  4. Glide Big Tables forces us the developer to build cleaner

I’ve stayed clear from Glide Big Tables because in general I am more comfortable staying away from the edges of experimentation. For a long time, I’ve felt that GBTs were still in the prototype and testing phase, and not yet a product I would be comfortable building on, certainly due to my own limitations.

But Art’s comment made me wonder: is it now time to make the switch and to seriously (for me) start building on Glide Big Tables? If so, for all tables like Art does it – expect for the Users table and helper tables – or would the adoption of Glide Big Tables be more nuanced, such as suggested by Darren below (transactional tables, chat)?

Thanks in advanced for any insights and personal experience you might be able to share.

6

Not until I see less challenges in building computation columns around it, but that day may come soon.

At the moment, there’s too much hopping around we have to do to be able to build a working app with solely Big Tables. I don’t see a reason why you have to go for Big Tables first if you understand your usage won’t go that high.

1 Like
7

But the 100 row limit for RollUps make Big Tables nearly worthless as the source for dashboards / totals. Or am I missing something ?

TIA

8

RollUps not limited to 100 rows in GBT
Lookups and joined list from GBT limited to 100 results

1 Like
9

As described above GBT forcing as to develop not like in Google sheet but like DB.
When you create in GT, you don’t have to explore to advance and develop step by step. But very quickly your app became like a common GS - slow.
With GBT you need explore, investigate, design, redesign and then to build and rebuild. And this takes much more time to build(edit) an app. But the result you can create very complex and fast app if need.
I think.

3 Likes
10

Yes. You are.