# 🧲 The QUERY Column: One Column to Rule Them All!

**URL:** <https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532>\
**Category:** Ask for Help\
**Created:** [May 9, 2023, 11:52am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532 "2023-05-09T11:52:13Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\
**Post date:** [May 12, 2023, 11:54pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/21 "2023-05-12T23:54:32Z")

</div>

I’ve experimented a little further, here’s how far I got:

- Parent-to-children Relation. I got the same output with a Query.
- Children-to-single-parent Relation. I got the same output with a Query.
- Children-to-many-parents Relation. I got the same output with a Query.
- Self-relation to create a unique list. I got the same output with a Query.

For those use cases which seem to be the main ones, Relation is included in Query. Meaning I might as well ditch Relation. Relation seems to be redundant now.

This does not take into account performance considerations.

---

<div class="post-metadata">

**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\
**Post date:** [May 12, 2023, 11:59pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/22 "2023-05-12T23:59:22Z")

</div>

I might still use a self-relation to determine the unique rows of a table (along a given column). For instance if name has a, b, c, a, b, c, then the output on the first three rows would be a, b, c (self-relation with single match, lookup.RowID, if-the-else where lookup.RowID == RowID).

---

<div class="post-metadata">

**Author:** ![Robert\_Petitto](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/robert_petitto/32/25193_2.png) [@Robert\_Petitto](https://community.glideapps.com/u/Robert_Petitto)\
**Post date:** [May 13, 2023, 12:07am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/23 "2023-05-13T00:07:41Z")

</div>

> [@nathanaelb](#):
>
> This does not take into account performance considerations.

Exactly. Querying IS SUPER powerful, but querying a huge table and using lots of conditions won’t be AS efficient as creating the relation first and then querying the relation…but then you’re using 2 computed columns, so it’s a trade off I guess.

---

<div class="post-metadata">

**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\
**Post date:** [May 13, 2023, 12:19am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/24 "2023-05-13T00:19:14Z")

</div>

Further observations:

- Clearly (I hesitate to use this term) Query is meant to replace Relation. Query is more powerful than Relation, it’s somewhat easier to set up, it’s more logical, Relation is included in Query. The only issue is that Relation is still quicker than Query, which is an issue if one would like to use Query only instead of Relation.

- We now have two computed columns that are extremely similar, it feels messy. It’s like those 4 title components that are basically 1 single component, or card and grid that are basically 1 style.

- I haven’t tried it yet, but I don’t think I would want to query a relation. Since Relation is included in Query, that would be like querying a Query. That doesn’t feel right.

---

<div class="post-metadata">

**Author:** ![Robert\_Petitto](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/robert_petitto/32/25193_2.png) [@Robert\_Petitto](https://community.glideapps.com/u/Robert_Petitto)\
**Post date:** [May 13, 2023, 1:53am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/25 "2023-05-13T01:53:57Z")

</div>

Fair assessment!

I’m only going based off of what Glide is telling us. If they say a relation is faster than a query, I have to believe them.

All this to say, I’m sure improvements will be made to query, and perhaps it will eventually replace relations. Who knows?!

---

<div class="post-metadata">

**Author:** ![Darren\_Murphy](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/darren_murphy/32/47326_2.png) [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)\
**Post date:** [May 13, 2023, 4:19am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/26 "2023-05-13T04:19:47Z")

</div>

> [@nathanaelb](#):
>
> And what is this single/first setting anyway, is that a thing in traditional programming? The self single Relation is useful in Glide to create unique lists of rows, but it got me wondering why single Relation outputs the first row found. Considering the data in tables is not ordered, it feels quite arbitrary that a single Relation would return the first result.

So what would be less arbitrary?  
The third from the start?  
The second last one?  
The one in the middle?  
What if there was only one match?

This is a common pattern in computing. As soon as you find a match, exit the loop and move on.  
Think about the way that the if-then-else column works, it’s exactly the same. The first condition that matches determines the result 🙂

---

<div class="post-metadata">

**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\
**Post date:** [May 13, 2023, 7:03am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/27 "2023-05-13T07:03:03Z")

</div>

> [@Darren\_Murphy](#):
>
> This is a common pattern in computing. As soon as you find a match, exit the loop and move on.

Phrasing it like you did makes so much more sense to me. I never saw a single Relation as an iterative loop but rather as a vertical scan. Perhaps these are the same but loop plus find match plus exit loop makes more sense to me. Programming never ceases to amaze me.

What I did to achieve this with Query was filter to find all (since Query is a match multiple) then limit to 1 (first from the bottom or top). With Query we seem to lose this ability to exit the loop when a match is found.

I like Query _a lot_.

---

<div class="post-metadata">

**Author:** ![gvalero](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/gvalero/32/1037_2.png) [@gvalero](https://community.glideapps.com/u/gvalero)\
**Post date:** [May 13, 2023, 2:32pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/28 "2023-05-13T14:32:15Z")

</div>

> [@nathanaelb](#):
>
> I might still use a self-relation to determine the unique rows of a table (along a given column). For instance if name has a, b, c, a, b, c, then the output on the first three rows would be a, b, c (self-relation with single match, lookup.RowID, if-the-else where lookup.RowID == RowID).

Hola!

When I read the term “self-relation” something strange happens in my eyes 🥴

In my point of view, a **self-relation** (also called **self-join** ) should be avoided and not used as much as possible.

A self-join is a join in which a table is joined with itself, and when used, generally indicates that the table is non-normalized in 90% of cases.

This may not be a problem for a small table (perhaps less than 2k-3k rows), but using a large, complex table with higher concurrency (moves) will lead to poor performance and degrade your query response time. It is a fact!

Google even states that this trick should be avoided if you are going to use their BigQuery database, which is column-based and not row-based like traditional RDBMS databases (what we use in Glide).

Is a relation faster than a query? I think so and the reason is because the Query column needs to classify and discard the data based on the filters set on it. The query has more work and calculations to do than a relation.

Instead, the relation simply joins 2 tables using a (common) key field/column between them and creates a new and larger virtual table ready to be parsed.  
We could have had a better tool if we could set Query to the fields/columns to use and not just the filters.

I mean, now we are using a standard Query clause like this in Glide:

> Select \*  
> From MyTable  
> Where Filter1 AND|OR Filter2 AND|OR … FilterN  
> Order by Column … ASC|DESC;  
> Limit N

but it could be better if we can get the following:

> Select **Column1, Column2, Column3** …  
> From MyTable  
> Where Filter1 AND|OR Filter2 AND|OR … FilterN  
> Order by Column … ASC|DESC;  
> Limit N

A query with few columns and no filters will be faster than the current Query column or even the current Relation column.

Can we have this enhancement for the next Query version?

Saludos a todos!

---

<div class="post-metadata">

**Author:** ![Eden](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/eden/32/18651_2.png) [@Eden](https://community.glideapps.com/u/Eden)\
**Post date:** [May 13, 2023, 10:51pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/29 "2023-05-13T22:51:35Z")

</div>

@MattLB @Robert_Petitto This sounds interesting…  
Could you elaborate?

Sounds like something which could be super useful for building reports In general without having to add many columns or tables.

---

<div class="post-metadata">

**Author:** ![nathanaelb](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/nathanaelb/32/43079_2.png) [@nathanaelb](https://community.glideapps.com/u/nathanaelb)\
**Post date:** [May 14, 2023, 8:25am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/30 "2023-05-14T08:25:32Z")

</div>

I agree, Query is practical for cohort analysis, i.e. reports. With Relation, reporting requires a Template column, a self multiple Relation and a Rollup. With Query, reporting requires a Query and a Rollup. Query is much easier to understand than Template + self Relation.

---

<div class="post-metadata">

**Author:** ![Cameraville](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/cameraville/32/60231_2.png) [@Cameraville](https://community.glideapps.com/u/Cameraville)\
**Post date:** [May 14, 2023, 9:14am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/31 "2023-05-14T09:14:15Z")

</div>

If you need to create a traditional Relation from a query, you can always using Single Value to pull in the first queried item’s row ID, then create a relation using that. Not hard to figure out but just a tip I came across.

---

<div class="post-metadata">

**Author:** ![Robert\_Petitto](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/robert_petitto/32/25193_2.png) [@Robert\_Petitto](https://community.glideapps.com/u/Robert_Petitto)\
**Post date:** [May 15, 2023, 12:06pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/32 "2023-05-15T12:06:41Z")

</div>

> [@Cameraville](#):
>
> you can always using Single Value to pull in the first queried item’s row ID, then create a relation using that. Not hard to figure out but just a tip I came across.

Actually, single value → Whole row would accomplish this in one step.

> [@Mastering the Mighty Single Value → WHOLE ROW](https://community.glideapps.com/t/mastering-the-mighty-single-value-whole-row/57071):
>
> Learn to master the Single Value → WHOLE ROW feature Use this feature to easily link to the details screen of a: point_right home screen… point_right sign up form… point_right about page… point_right …and more! [[Glide: Custom Forms with Single Value → Whole Row] ](https://www.youtube.com/watch?v=Dr1pCuL2Mg0) Thanks to @Darren_Murphy for one of the ideas presented in this video!

---

<div class="post-metadata">

**Author:** ![bru](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/bru/32/37841_2.png) [@bru](https://community.glideapps.com/u/bru)\
**Post date:** [May 16, 2023, 12:48pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/33 "2023-05-16T12:48:12Z")

</div>

Does the query column use updates? Know queries to big tables do and am curious if this works at all in the same way. Thanks so much for your help!

---

<div class="post-metadata">

**Author:** ![Robert\_Petitto](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/robert_petitto/32/25193_2.png) [@Robert\_Petitto](https://community.glideapps.com/u/Robert_Petitto)\
**Post date:** [May 16, 2023, 1:07pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/34 "2023-05-16T13:07:52Z")

</div>

It shouldn’t. It’s just another type of computed column, like a relation.

---

<div class="post-metadata">

**Author:** ![BLA\_68](https://avatars.discourse-cdn.com/v4/letter/b/977dab/32.png) [@BLA\_68](https://community.glideapps.com/u/BLA_68)\
**Post date:** [May 18, 2023, 7:02pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/35 "2023-05-18T19:02:47Z")

</div>

Haven’t tested this extensively, but having a sort option in query, combined with the sort option in a component allows for secondary sorting. So you can achieve this:

Apple 1 oz  
Apple 2 oz  
Banana 1 oz  
Banana 3 oz

etc.

---

<div class="post-metadata">

**Author:** ![Robert\_Petitto](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/robert_petitto/32/25193_2.png) [@Robert\_Petitto](https://community.glideapps.com/u/Robert_Petitto)\
**Post date:** [May 18, 2023, 7:17pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/36 "2023-05-18T19:17:09Z")

</div>

> [@BLA\_68](#):
>
> combined with the sort option in a component

Actually, I think the sorting in the component would override the sorting in the query.

---

<div class="post-metadata">

**Author:** ![BLA\_68](https://avatars.discourse-cdn.com/v4/letter/b/977dab/32.png) [@BLA\_68](https://community.glideapps.com/u/BLA_68)\
**Post date:** [May 19, 2023, 9:09pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/37 "2023-05-19T21:09:50Z")

</div>

Might be just an anomaly of this example, but let me show you what I’m seeing.  
So here is the sheet order:

 ![Screenshot 2023-05-19 at 2.03.12 PM](https://us1.discourse-cdn.com/flex002/uploads/glideapps/original/3X/d/0/d0e57968bc64c151c33c788c3304f616512c238a.png)

Here’s how it displays if the query is sorted by Number, but the component has no sort.

 ![Screenshot 2023-05-19 at 2.04.28 PM](https://us1.discourse-cdn.com/flex002/uploads/glideapps/original/3X/1/f/1fdc18f247b8569a29a2a250c7db7e98f5ce1887.png)

If I then add sort by Name to the component I get this:

 ![Screenshot 2023-05-19 at 2.04.52 PM](https://us1.discourse-cdn.com/flex002/uploads/glideapps/original/3X/c/8/c8bdd15581838bacb257249e02a02fae1b2dd9b7.png)  
Which appears to be successfully sorting all of the ABs first, then within that sorting by the number, then BC then SB, etc…

---

<div class="post-metadata">

**Author:** ![Robert\_Petitto](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/robert_petitto/32/25193_2.png) [@Robert\_Petitto](https://community.glideapps.com/u/Robert_Petitto)\
**Post date:** [May 19, 2023, 9:25pm UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/38 "2023-05-19T21:25:52Z")

</div>

I stand corrected!

---

<div class="post-metadata">

**Author:** ![Eden](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/eden/32/18651_2.png) [@Eden](https://community.glideapps.com/u/Eden)\
**Post date:** [June 1, 2023, 1:34am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/39 "2023-06-01T01:34:10Z")

</div>

I wonder what’s the best method to use Glide for many reports without

1. Resorting to separate tables per report.
2. Keep reports columns separate of the Base data tables/columns so to keep the backend simple.

All that- while maintaining a consistent and logical structure for report building.

---

<div class="post-metadata">

**Author:** ![Darren\_Murphy](https://sea2.discourse-cdn.com/flex002/user_avatar/community.glideapps.com/darren_murphy/32/47326_2.png) [@Darren\_Murphy](https://community.glideapps.com/u/Darren_Murphy)\
**Post date:** [June 1, 2023, 1:43am UTC](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532/40 "2023-06-01T01:43:19Z")

</div>

I think 1. and 2. are almost mutually exclusive.

My practice is to create a separate table for each set of reports/charts. For example:

 ![CleanShot 2023-06-01 at 09.38.39@2x](https://us1.discourse-cdn.com/flex002/uploads/glideapps/original/3X/e/6/e6ee3d174dffa28afd41e72b9df967cb96493eb0.png)

This achieves the goal of keeping the data tables as clean and uncluttered as possible, but it also creates a logical separation of concerns and makes maintenance/debugging much simpler. Because each report has it’s own table, I know exactly where to look if something breaks.

[Previous page](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532.md?page=1)

[Next page](https://community.glideapps.com/t/the-query-column-one-column-to-rule-them-all/61532.md?page=3)
