I’m currently using a large number of databases (ranging from 50 to 100). To display all relations in an entity using separate field resuls in an enormous list of fields, thus unworkable.
To address this, I use a single field that consolidates relations from all relevant databases. This approach significantly declutters the interface and saves screen space.
Tension:
The need to manually add each of the 50+ databases individually in views. This process is time-consuming and repetitive.
Proposed Solution: Database collections
These collections would function similarly to individual databases but with added efficiency: One-Click Relation Setup: You could create 50 or more relations with a single click, vastly improving setup time. This is useful for views that need to aggregate a lot of databases, such as:
Recently Modified Entities
High Priority
Parent Project
Each view often shares common relationships or properties across multiple databases (e.g., modification date, priority status database relation, or parent project relation).
Maybe you encountered another use case where database collections could be useful? Please share, thanks.
And a quick way to create a collection, would be to choose: aggregate all databases in the new collection that contain relationship XYZ.
For example 'aggregate all databases in a new collection that contain relationship “Parent Project”. This would aggregate all project content types (in my case that would cover approx 50 databases).
It would be even better if the collection would auto-update itself to include new databases that use the same relation, or remove a database from the collection if its shared relation is removed from it.
I mean I now combine databases in one field. (Maybe the term consolidate would be appropriate for the requested database collection). So I now have to manually add all relevant databases in one field, like for example in this entity display of type ‘Index’, I renamed the Page relations field to ‘Content’ and added a bunch of databases that all relate to an index entity:
I get that it takes some time initially, but why is it repetitive?
Do you mean that almost every db is connected to almost every other db, so that you need to create these ‘aggregated views’ for many entity types?
If so, it begs the question why such a hyperconnected structure is felt to be suitable for your needs…
When I see workspaces with lots of relations, it often points to inefficient structural design. Not saying this is necessarily the case for you, but I wonder what your use case is…
Ah, I see. In my head that’s ‘combining in a view’. Combining relations in an actual field would be really awesome (let’s say combine ‘project’ with ‘program’ in one field) but that’s not possible atm.
We often combine different databases in one view in a way you showed in your screenshot.
But it’s always per use case. So example: combine all forms, docs and emails of a contact in 1 view (so we save space).
However, we never do that repetitive, since it’s per use case (and those use cases only occur once).
Also, we make use of the relation page itself.
So priority is a database. If we open ‘high’ we’ll see on that page all entities/databases/relations with priority ‘high’.
In those screens we do like the separate views/containers so you can see ‘oh, these are tasks with high prio’ and ‘these are projects with high prio’.
Same for parent project. There, we also don’t combine stuff in 1 view. So each view has only one linked database and we show tasks, notes, resources separate.
So TLDR: can’t think of a use case where this comes handy in our workspace.
Also: combining so many databases/relations when it’s not very necessary can also slow your system down. And it may cause problems in the future when you extend the amount of databases or the total size of your workspace schema.
