# Database 'collections' to reuse in new views and relations

**URL:** <https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523>\
**Category:** Ideas & Features\
**Created:** [December 12, 2023, 6:29pm UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523 "2023-12-12T18:29:15Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\
**Post date:** [December 12, 2023, 6:29pm UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523/1 "2023-12-12T18:29:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\
**Post date:** [December 12, 2023, 6:35pm UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523/2 "2023-12-12T18:35:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![YvetteLans](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yvettelans/32/6101_2.png) [@YvetteLans](https://community.fibery.io/u/YvetteLans)\
**Post date:** [December 12, 2023, 8:13pm UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523/3 "2023-12-12T20:13:55Z")

</div>

> [@Yuri\_BC](#):
>
> 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.

Really curious: how do you consolidatie relations from all relevant databases in a single field?

---

<div class="post-metadata">

**Author:** ![Yuri\_BC](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yuri_bc/32/8803_2.png) [@Yuri\_BC](https://community.fibery.io/u/Yuri_BC)\
**Post date:** [December 12, 2023, 9:10pm UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523/4 "2023-12-12T21:10:43Z")

</div>

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:

 ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/a/a900aec0ef70c3db3010a5c68eacd2be1c4e286a.png)

---

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [December 12, 2023, 9:23pm UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523/5 "2023-12-12T21:23:17Z")

</div>

> [@Yuri\_BC](#):
>
> This process is time-consuming and repetitive.

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…

---

<div class="post-metadata">

**Author:** ![YvetteLans](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/yvettelans/32/6101_2.png) [@YvetteLans](https://community.fibery.io/u/YvetteLans)\
**Post date:** [December 13, 2023, 8:34am UTC](https://community.fibery.io/t/database-collections-to-reuse-in-new-views-and-relations/5523/6 "2023-12-13T08:34:20Z")

</div>

> [@Yuri\_BC](#):
>
> 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:

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.