For example, generally speaking, we will regard the task as a whole entity, but if the task is divided into two types, one is a single-person task and the other is a multi-person task, and these two types have completely different processing processes, we tend to split it into two different entities to manage separately, but sometimes if we force the two to be the same entity, we can also carry out subsequent operations, so this makes me very confused. It seems that separation and non-separation have their own advantages and disadvantages, so we want to see what everyone thinks.
I really wanna learn from the other players!
Personal preference? 
I know that’s not very useful, but I haven’t figured out a ruleset that works in every scenario. Generally, I go for as few types as possible, and I try to use single-selects as often as possible instead of relations, except when I’d need features only available in relations like names as formulas, sorting and filtering, etc.
Without polymorphism, it can be hard to figure out a good structure, but I’ve found that while maybe being “larger”, the application becomes the most versatile when you build out your tables in a way that mirrors reality most accurately.
For example, prior to Fibery, at my job, I set up the old CRM with just a few types. One type was a “person/family/legal entity/sales lead/sales opportunity” all rolled into one, and that just didn’t scale once we started growing. Now, every one of those has been separated out into it’s own type (families and legal entities have been merged into one, which works for our setup). The potential for automation with this structure is blowing my mind, and we’re going to be able to do the work of like 10 FTEs with Fibery (it’s a company of 20-30, so that’s a big deal)
One interesting merging of types is something I did yesterday. We are keeping track of available and sold territories in Fibery, and I’ve been developing an automated naming convention for these territories. Each territory is part of a “Geophy”, and each Geophy can have a parent Geophy (so you get an infinitely nestable structure). A Geophy is table/type that can represent any sort of geological/geographic/political boundary or area, like Geographic region, Metropolitan Area, City, etc. They’re all sort of different “types”, but we can represent them with one type hierarchically, since all we are looking at is their name, their population count, and whether or not they are well-known.
By the way, if you haven’t discovered the power of relating a type to itself, then being able to use formulas to query in an infinite chain up that relation, OR to be able to group and nest by the same type in list view, TRY IT! It’s way cool. Good job @mdubakov 
I feel like that should be advertised more prominently.
Anyways, @hansonreas what is your use case? What are you trying to solve? What’s your vision?
1 Like