I was disappointed with the grids

Get Help
1

Good morning, I am trying to use grids instead of lists to represent hierarchical data.
Lists have the defect of not displaying the name of the fields and this limits them in representing non-self explanatory data. Typically, fields representing numbers create obvious and ineradicable confusion (height, width, length for example). Going over the cell with the mouse makes the field name explicit, but it is an inconvenient solution.
Tables, as is well known, are a flat structure unsuitable for representing hierarchical data.
You have opted for a grid object, more advanced and complex than a table, which is a kind of hybrid between a table and a list and which in theory should represent hierarchies without running into the limitations of lists, that is, displaying field names and thus solving the problem of the lack of clarity of lists.
In reality this is not the case.
Let us take two databases: books and book references. The two databases have different fields. For the books database we have: title (name), author, publisher, language, year of publication, format, number of pages, and we are already at 7 fields, but many more can be added. For the book reference database we have: title (name), and this first field is superimposable on the book title field (i.e., it is in the same column), topic, importance, reliability, difficulty, start page, end page, and we are already at 7 fields different from the book database.
Where do we put the 7 fields in the second database?
From left to right do we put the fields from the book database and then on the tail those from the child database references?
But doing it this way doesn’t fit! I am sorry but that is not the solution.

Here are the two databases represented with lists:

immagine
immagine2560Ă—1440 303 KB

And here instead is the representation with grids:

immagine
immagine2560Ă—1440 405 KB

As you can see between the two options, the first one, although unsatisfactory, is preferable and all in all more readable, once you know the names of the fields (by mousing over the ones you don’t understand).
Then let’s not talk about adding additional child databases, which is absolutely impractical with grids.
The only case where grids win is with self-joins, so hierarchical databases where the child database and the parent database are the same. It works because the fields are the same and the highlighted problem is not created.

What solution should you adopt to solve the flaw that lists have? I remember last year suggesting this. The most viable solution is the one pioneered in Microsoft Access of sub-sheets in tables, nesting the data. It is the only one that can work. I couldn’t tell you if there are web objects that replicate this functionality.
Here is an example taken from the web.

immagine
immagine705Ă—417 105 KB

Regards.

1 Like
2

Browsing the net, I found this example:

immagine
immagine1366Ă—768 136 KB

See also here: How to Create Nested Grid using Angular 8

immagine
immagine1030Ă—628 111 KB

3

What you’re asking for is a essentially table inside of a table, which I doubt you’ll find in many tools like Fibery.

One way to do something similar, would be creating a document and then embedding different tables inside of the document.

Another thing that might help (that isn’t possible yet, but @mdubakov has mentioned is coming soon) could be the “group by any field” feature. I’m not sure exactly how it will work yet, but it would be awesome if the columns/fields in each grouping could be controlled independently for each. For example, group by “Project Type” and for “A” projects, columns A, B & C are shown, and for “B” projects, columns D, E & F are shown. Even better, if “Project Type” was an entity and we could also display its fields in the header of the group (similar to how the rows in list view work currently) it would be absolutely perfect. That’s how monday.com does it and if their formulas and automations were half as good as Fibery’s is, I likely wouldn’t even be here right now. :stuck_out_tongue:

4

To solve your first problem, can’t you just name the fields of both tables the same? Or some of them the same? If table 1 has column "ABC and table 2 has column “XYZ” - you can make a relationship between the two and renamed the “XYZ” column to “ABC”, no? Or, renamed them bot “GGGg” and then choose to show column GGG in your grid - then you have one column showing data from the two? I might be missing something and way off the mark. Each column, regardless of name, is associated with a relationship so what you choose as the column names, viewable in the NEW TABLE (OLD GRID) can be exactly what you make them, and as intuitive as you choose?

I understand what you are saying about your second problem, however, I don’t look at this as a limitation of Fibery, but instead, an advance, by using entities that look like documents (instead of documents) you can then embeds, you have one-to-many relationships at the bottom, you can even create new VIEWS entirely customized to your needs and stick them in what looks and functions like a document. I love that and so does my team.

Again, I could be misunderstanding what you’re saying, I seem to do that often! :innocent:

2 Likes
5

I thank you for the advice. But the two databases in the example have different fields. You can’t name the fields the same, because they represent different properties.
What you say is accomplished when the two databases are the same database bound to itself by a 1-to-many relationship. In that case there the fields are the same and the representation with grids is optimal.
Have a nice day.

6

Indeed. @DiegoKamp are you aware of any tools with a non-fixed schema that support tables-within-tables?

7

Sorry Chris, I only found the examples given above.
I am only a project manager, in banking and I work a lot on databases, but not with web languages, which I know superficially.
In my advice I try to raise basic questions about the architecture of Fibery, particularly for hierarchy management.
Fibery is the only system known to me that not only allows the structural setup of hierarchies but also addresses and tries to solve their visual representation.
With lists it partially succeeds. Despite their limitations, lists are the most advanced representations of hierarchies I have seen to date.
In contrast, grids are not good for representing hierarchies; it is a wrong way to go.
As explained above, grids are adequate for representing table-based hierarchies in self-join, for that kind of hierarchy they are great.
You still need to work on them.
Have a good evening.

8

The feedback is appreciated.
When I asked about other tools, it was partly so that we could seek inspiration for how best to deliver on the need, not because I doubted that a need existed :+1:

2 Likes