Could use some strategic help from the gurus - am I doing Fibery wrong?

[Robert_B]

Hi all, when I signed up for Fibery a while back I just started building stuff and Polina and I spoke and it was clear I was building a big mess.

So I kind of started over and it seems like it’s evolving into a another big mess.

There are a few core concepts I don’t really understand. I THINK Fibery advocates for databases with fewer columns and lots of views. Is that right? Does Fibery suggest fewer or more database?

If you look at the image above, those are columns that I want on all task-like items. EM, WF, SUB TAGS, CAT, MOD, TYPE, !, TAGS - are all items I created - WF, SUB TAGS, TAGS are relations while the other single or multi select.

Let’s say I have 20 different TYPES. Things like these 10:

1. Project
2. Action
3. Feedback
4. Task
5. Interview
6. Loom
7. Report
8. Audit
9. Event
10. Request

The first go-round I started creating tons of databases for these kinds of things and more. Then I evolved to create fewer, but I find myself recreating the same database structure for many of them. Recently, though, I’ve really learned the power of multiple rows (including indented ones) in views and smartfolders - to show things they way I want to (many-to-many relationships).

For instance, in trying to setup a Wiki kind of thing, I saw that you use the concept of Guides and Sub-Guides, though I think Sub-Guides is just the Guides database.

I have also found that a lot of things are easier if you can just “ADD” them [the + button everywhere in Fiber] - e.g. its easier to add a Task, then to add an entity/item of Type Task or an Item of Type Resource.

So now I found cases where it seems like the more databases the better. For instance my management team wants to see pages indented under their meeting agendas - so they default to using Documents - but I want to use the more robust entities (to track those items above like Tags and Sub Tags) - so I created a database for Notebook and Page and so they can see those and create those in the smart folder that shows agendas/meetings. They will appear like Documents but will have the additional flexibility of a powerful entity.

Now, though, I’m confused. Is it best to do more databases after all? And if you look below you see I have tons of relations. Is that bad? I think it’s another mess.

The thing is, if I want to track the same things on scores of items [EM, WF, SUB TAGS, CAT, MOD, TYPE, !, TAGS] then I find myself spending a lot of time building database because “selects” don’t work when sharing as template/import is used - and relations don’t stay when using that method.

So if you had those 10 TYPES above. Would you make 10 databases? Or 1 database with 10 types. Since I switched to the latter, I’m finding it more unwieldy to use.

And most important, is there a better way of doing this? Like could you have ONE database just for these: EM, WF, SUB TAGS, CAT, MOD, TYPE, !, TAGS - and somehow “attach” it - and all it’s columns - to all the other databases?

Thanks in advance for any help you can provide.

Here’s what my relations look like. Is this crazy?

[mdubakov]

This is always a hard to question to answer without deep context. Some brief thoughts:

1. In the list above I’d probably created Database for every item. Loon is unclear, is it just a video? Why it needs a database? Audit and Event are also unclear. What are these things?
2. Domain modelling is always hard. Normalization is something few people know well. Some general rules:

• If you need many unique fields for two types (including relations), these are probably two different databases
• If you can apply rule “kind of” to two types, you may try to use single database for them with a single-select field as a differentiator, but taking into consideration rule above
• avoid duplicates, like Task database in some space A, and Task database in some space B. It is always suspicious.
• Databases named Page and Notebook are suspicious. If they are very generic things that can be linked to anything, maybe Docs are also OK.

3. It is unclear why you need many fields in all task-like databases. What is TYPE, CAT, MOD, WF?

As a reference, here is our Fibery workspace. We are growing it from 2018, and now we have 35 ppl in the company. As you see, not so many relations.

Every Space is in general a process.

It would be interesting to dig into your schema deeper and understand main ideas behind its design.

[Chr1sG]

I would also add that when I see that there are lots of relations (not necessarily lots of dbs) then I wonder if some of the relations should actually be replaced with lookups.
For example, if you have Products, Projects, Tasks and Users, perhaps it makes sense to link a Project to a specific Product, and a Task to a specific Project, and Users to one or more Tasks.
It isn’t necessary to link Tasks to Products, since Tasks can be found from a lookup on the Projects. Similarly, if I want to know which Projects a User is working on, there is no need for a direct relation between Users and Projects, since I can look up via the Task relationship.

It’s always worth asking yourself if you can infer how entities are connected, rather than adding a direct relation and linking things manually.