# Generic vs. Granular entities (when to split DBs) **URL:** \ **Category:** Get Help\ **Created:** [February 20, 2024, 2:54pm UTC](https://community.fibery.io/t/generic-vs-granular-entities-when-to-split-dbs/5882 "2024-02-20T14:54:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Ryan\_Dejaegher](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ryan_dejaegher/32/8050_2.png) [@Ryan\_Dejaegher](https://community.fibery.io/u/Ryan_Dejaegher)\ **Post date:** [February 20, 2024, 2:54pm UTC](https://community.fibery.io/t/generic-vs-granular-entities-when-to-split-dbs/5882/1 "2024-02-20T14:54:00Z")
Hi all, curious to hear others thoughts on this. I read the latest version of “How Fibery uses Fibery” and thought it was interesting that they have a database specifically for DevTasks (_any task that doesn’t add value to the end user_) I’m wondering how others think about the distinction between generic (Project, task) and granular databases (Bugs, DevTasks, Test tasks) Generic is the most straightforward to setup but it also feels like it gets messy as you add more contextual fields. For example some of my tasks are really bugs, in order to give more context to the bug I now have to add a field for something like affected area. Maybe the better question is how far do you push the generic approach before it’s worth it to switch to more specific databases? ---
**Author:** ![njyo](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/njyo/32/923_2.png) [@njyo](https://community.fibery.io/u/njyo)\ **Post date:** [February 21, 2024, 4:01am UTC](https://community.fibery.io/t/generic-vs-granular-entities-when-to-split-dbs/5882/2 "2024-02-21T04:01:36Z")
Good question! We have not taken a purist approach to the dilemma and thus have a mix of granular entities (e.g. Task and Build Task, Client Org and Partner Org) but also some generic ones (Meeting, Person) with loads of partially relevant fields. I would really want to have inheritance across the entities, as that would allow for common fields with granular extensions: > [@FRQ: Database Inheritance](https://community.fibery.io/t/frq-database-inheritance/4528): > > Hi, For certain types of databases (i.e. Tasks, People, Organisations, Tools) I would like to have the ability to inherit/extend databases. For example: I want a base database called Person which has a few basic fields: given name, surname, email, phone, etc. I’ll have database called Staff that extends Person, which in addition has fields like: join date, role, salary, etc. I’ll have a database called Contact that extends Person, which adds fields like: company, meetings, etc. I’ll have a d… ---
**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:** [February 21, 2024, 6:12pm UTC](https://community.fibery.io/t/generic-vs-granular-entities-when-to-split-dbs/5882/3 "2024-02-21T18:12:53Z")
We plan to roll out improvements to entity view in the course of this year, which may help with situations where a single database has a number of fields which are not applicable in all circumstances. In other words, a Task could be views through a ‘Development task’ lens, a ‘Marketing task’ lens, even though all the Task the entities live in the same db. ---
**Author:** ![Ryan\_Dejaegher](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ryan_dejaegher/32/8050_2.png) [@Ryan\_Dejaegher](https://community.fibery.io/u/Ryan_Dejaegher)\ **Post date:** [February 21, 2024, 6:50pm UTC](https://community.fibery.io/t/generic-vs-granular-entities-when-to-split-dbs/5882/4 "2024-02-21T18:50:07Z")
Ahh that is super helpful. This feels like it fits more with of a bottom-up approach where the necessary fields emerge through actual usage vs. trying to plan the perfect database/fields top-down