Thanks for responding, both. I’m trying deliberately not to specify a particular use case, because I’m searching for a general principle or convention. If you have two similar-ish types of entities (for example, “customers” and “investors” are both subtypes of “people”), should they be in one larger database (called “people”) designed to capture both customers and investors and all other categories of people, or create a different database for each type of person? Let’s say that all types of people have 4-5 fields in common (examples: name, phone number, email, linkedin URL, etc) and 4-5 types of fields that are unique to that type of person. If I have one master database for all types of people, then the number of fields grows with the number of types of people. Once there are 10 types of people, there’s 50+ fields, and the database has grown quite complex (and it will also be somewhat sparse). It will be painful to administer this database, but maybe that’s OK because maybe then you only need to configure a different grid or table view for each type that shows only the 5-10 relevant fields one time for each type.
At first, I found that too complex and unwieldy so I was creating multiple databases for different types of people, and I was replicating some fields, and found that to be painful.
Is there any way to copy a field from one database to a different database? For example, if I have a multi-select field called “category” and there are 10 different choices, it is painful to manually recreate the same field in a new database, and it would be much easier to have a way to copy the field including its choices from one database into a second database. For example, I have one mater database for “people” and another master database for “entities” (which are groups of people), and both people and entities can be assigned to common categories. Ideally, the “category” field is in sync between the two tables. So maybe I create a separate database called categories and use a relation instead of a multi-select? It seems like overkill because I “categories” doesn’t need to be its own database.
Furthermore, I tried exporting/backing up my data and it didn’t save any relations! I can’t afford to lose this type information when I backup my data. Is there any way for the data export to include the relations?! As the introductory video explains, relations are the “glue” of Fibery, so I hope you don’t lose them when you export your data, otherwise it’s not a good enough backup to me and I feel vulnerable that if something happens to Fibery, I will lose all of the contextual information that I depend on.
Also, can you copy an entire database from one space to another? I only see a way to convert a single entity into a new entity in a different database, but not a way to copy an entire database. This is also painful because only data for which the fields are identical between the two databases is retained! It just throws away data if it doesn’t find a match in the fields. which means I need to manually make sure that there are fields that match exactly.
What’s Intercom and where can I find it? I don’t see it mentioned anywhere at fibery.io.
Thanks, hopefully my questions will help someone else.