Good table naming conventions

Hi all,

Does anyone use a good data table title name convention? Is there like a list of these? What categories do you use?

Example: I do Booleans / Item / Item A / Item B
Issue is I am not sure that is good data category title / management. Just wanted to see what else people do to manage large datasets with ptoentially 100s of columns.

Thanks! :slight_smile: James

There’s a few posts regarding this floating around, but here is one with a few follow-up posts.

https://community.glideapps.com/t/what-kinds-of-columns-are-missing-in-glide/33473/100?u=jeff_hager

I wouldn’t say that I have a strict naming convention, but I like to prefix computed columns with their type.

As for column grouping, I’ve seen a couple of different ways that people group their columns with the ‘/’ character. Some will group by column type (all booleans, all relations, all IF columns, etc.). I personally tend to group by function. A lot of times I’ll have several columns that work together to perform a function or or columns that are related to each other, so I’ll end up grouping them together that way. That way it’s easier to collapse a group of columns that are related to each other or part of one function. Also, it’s much easier to find the column you need in the app…much like folder/file system. I explain a little more here.

4 Likes

I guess the first link is private, so I’ll post an excerpt below.

4 Likes

Personally I think a good combination of Grouping by function and prefixing by column type makes the most sense to me. Depends on what makes sense for you.

5 Likes

Hi @Dragonjamesx - It’s a good question, particularly if you are relatively new to Glide.

I come from a software dev background and so naming conventions are ingrained in my soul. My personal approach is to use grouping to denote context. However, I don’t actually use prefixes to denote data type since the GDE makes it quite simple to see this, particularly more recently with its differential display. Instead I aim for absolutely readability (in my eyes).

As an example, a row for a user might include columns like this:

  • Account / Email
  • Account / Name
  • Account / Phone
  • Tasks / Relation
  • Tasks / Count

The group gives context and the column name makes it as clear as possible to anybody viewing the app what the data represents. This also applies to me when I look back at an app after a few months absence.

As @Jeff_Hager and @Darren_Murphy both say, however, this is a personal decision BUT that doesn’t mean it’s something you should take lightly. I can guarantee you that a well-defined naming convention will be invaluable as the size and complexity of your app grows.

As an aside, your naming convention can also help as you think through the data structure for your app, helping to clarify entities and linkages. In the example above, group naming by context helps me think about what information from a user’s tasks I might want to surface within the user row.

In summary, it’s up to you, but definitely do it!

5 Likes

Thanks Jeff, this is great stuff. I think I may try some of these when I start building out my app - I am doing a football (soccer for the other side of the pond) app :slight_smile:

1 Like

Perfect, thanks @V88 I think I will start something like that and see how that expands, thanks for the input.

All my relations are named as rel_tableFrom_tableTo_Context. So in what ever element I use the relation I immediately know what data are in there.
For column type I use prefixes, for the context I’m starting to use grouping.
But overall I try to have a table for each screen, hence most computed columns in that table have a clear context anyway.

2 Likes

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.