For example, I see this when I test:
If I have 101 clients in a table A and a relation to a big table B, does this mean that I can only look up data from that relation for 100 of those rows in table A?
Geepers.
If I try to select a lookup column from a relation to a big table in Layout and display it’s data, that column is not in the list of columns that I can select.
Are Big Tables a completely different thing to Glide Tables and are they not intended to be used relations? I though they were Glide Tables with more storage more or less.
Seems like they are only useful for displaying data on their own screen.
This is normal. It’s because with Big Tables the data lives on the backend, and is only fetched on demand. It doesn’t affect the way the data is presented in the layout. Click on any of those cells and you’ll see the returned value.
It depends which types of columns are being referenced. For non-computed columns, and a small subset of computed columns, there is no limit. If you’re seeing that warning, it means that you are referencing an unsupported computed column (either directly of indirectly).
1 Like
If you look at the screenshot above, I had a relation from A to B (B is a big table, the column is a number).
I’m referencing a number column, not a computed column. The warning message called this a roll up column. I selected multiple relation so maybe it treats it as a roll up.
I’m basically trying to understand how to work with big tables if they work differently to glide tables, docs don’t make it super clear whether you can do basic stuff like show data from a relation or not 
How is the relation formed? Is it matching non-computed columns in both tables, or are there computed columns involved?
A lookup into a multiple relation will return an array, so it’s “kindof” a rollup, but I suspect that’s just a generic warning message that appears any time the 100 row limit applies.
Big Tables do take a little bit of getting used to, and you sometimes have to employ creative workarounds to get things done. But they are much faster than regular Glide tables, they work synchronously (which avoids the concurrency issues that affect regular tables), and of course they have much larger capacity.
Formed: a number column to a number column.
Without multiple lookup there were no matching records.
What else do I need to get used to vs. glide tables?
@Darren_Murphy do you know of a table or resource comparing glide tables to big tables? I’m pretty hand with glide tables and assumed big ones would be the same but with more rows. Now I get they are different, it would be great to have those difference summarised. This is different to the limitations of big tables in Glide’s docs. I think those docs assume you know as much as the Glide team sometimes 
Any help appreciated!
Maybe a useful read. I found myself in a similar situation you are in a few months ago. (And I’m still in it.)
2 Likes
thanks man, apprecaite it.
If only there were docs that were super clear on both the differences between GT and BT as well as how to use BTs. I think there is a lot of assumed knowledge in the docs where they basically say “click here to create a new big table” but not how to use them to manage data beyond adding rows.
That’s a slight oversimplification, but the sentiment is accurate.
I’ve worked with DBs for years and Glide since 2020 so these aren’t new concepts. How this all works in Glide is not as clear as it could be esp if someone is new to both.
This was triggered for me when I created a relation between two tables using a matching text field, added a look up to a number field and wanted to display the number in my layout. That lookup wasn’t selectable as a field in a field component.
1 Like
Gonna ask the obvious question…is this through a multiple relation? If so, you can’t expect to see the Lookup column as an option for the fields component because it will be an array and a you can’t place an array into something that only holds a single value. A Joined List would be the better option instead of a Lookup.
1 Like
Similarly to you, I’ve always hesitated to use Glide Big Tables. I often hesitate to start using a feature that is still under development, and I’ve always felt that GBT was one of these features. I abhor maintenance and complexity in general, so using GBT has always felt like I was setting myself up for future maintenance and unwanted complexity. I have used Glide Big tables, but sparingly.
Glide evolves quickly as you know, and maintaining Glide Docs and University is a challenge for Glide. The way I see it, Docs and University cover the general corpus, aspects of the tool that are pretty much set or don’t change too often. The community forum adds further color and detail to this general knowledge, allowing us to discuss experiments, findings, edge cases, hacks and tricks (which I personally am not fond of), and more. The forum is a living and evolving knowledge base, and since Glide Big Tables are still evolving, I feel further discussions around GBT belong here. Until that product is “finalized” and then the documentation pertaining to it can be updated inside Docs and University.
And now I hope @NoCodeAndy will take notice. He knows my view on this. I would say the forum is a useful complementary tool to Docs and University, not only so that we all help each other out, but also as a repository of knowledge. Some (and this is an understatement I think) of the very best knowledge and resources related to Glide lives here in the forum. Glide has created, unfortunately, a parallel space in Slack, exclusive to Glide Experts, where they discuss various topics. Most of these topics belong in this community forum and would benefit the community at large. At the very minimum, if the discussions lived within a private group, the knowledge would be easily searchable and not siloed. In theory, Slack is decent for casual exchanges. In practice and in the way it is used, Slack is yet another space which plays the role of a knowledge repository. Yet Slack is notoriously a terrible tool for that: knowledge is archived beyond 90 days or so, topics are difficult to browse, the search function is terrible, and generally speaking it’s difficult to keep up with discussions. Some of Slack’s current channels such as the announcements might still have their place, but the experts-discussions channel belongs here in the forum.
2 Likes