# Specific vs generic database types

**URL:** <https://community.fibery.io/t/specific-vs-generic-database-types/2336>\
**Category:** Get Help\
**Tags:** flexible-domain\
**Created:** [December 24, 2021, 10:49am UTC](https://community.fibery.io/t/specific-vs-generic-database-types/2336 "2021-12-24T10:49:03Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![mdubakov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/mdubakov/32/10_2.png) [@mdubakov](https://community.fibery.io/u/mdubakov)\
**Post date:** [December 24, 2021, 12:18pm UTC](https://community.fibery.io/t/specific-vs-generic-database-types/2336/2 "2021-12-24T12:18:55Z")

</div>

This is always a hard problem. So far we are reluctant to add “is a” concept (inheritance) into Fibery, since it may complicate the system enormously. There are few heuristics that might help to decide:

1. If there are MANY different fields, then it is better to have different Databases. For example, if a Competitor has 5-10 unique fields, it is maybe better to have it as a separate DB
2. Duplication might be better than unification, since you can’t always foresee how data will evolve, and different DBs have better flexibility to handle it.
3. You may try to create an umbrella DB (Organization) that will have 1-1 link to Customer and Competitor, and setup automated rules or lookups to fetch data from Customers/Competitor into Organization. It’s a lot of work and it should have good arguments to go for it.
4. If you decide that Competitors and Customers should live in a single DB, the best way to differentiate them is just add a single select field with DB Type. Note that you will have to filter by this field in many places, so it may become more burden.

> [@pauljmackay](#):
>
> Does separate dbs create more of a proliferation of “Relation” fields? How to manage that? (maybe thats where using inline text links is better?)

This problem might be solved in future with polymorphic relations. It’s hard to implement and we will dig into it somewhere in Q3 2022 (not a promise).

> [@Polymorphic relations. When creating relation, ability to have many Types from which to choose, and not just one Type](https://community.fibery.io/t/polymorphic-relations-when-creating-relation-ability-to-have-many-types-from-which-to-choose-and-not-just-one-type/425):
>
> Hi again, As I get into Fibery, I am seeing that it could be useful for my use case to be able to choose amongst all types in a given App when creating a related field in another type. What I mean here is let’s say I have a type I’ve created in an App “Counterparties” called “vendor”. In this App I also have “partners” and “customers.” My vendors in turn provide 5 key services, which I have in another App. I’d like to link each service to the vendor. These services play a role in my Fibery …

---

_[View the full topic](https://community.fibery.io/t/specific-vs-generic-database-types/2336)._
