I want a “parent Type” of Project, with “sub-types” for Website Project and Brochure Project.
The parent Project Type will have things like Tasks relation, Assignments, Due date, etc.
The sub-types will have details unique to their project type.
What is the best way to model this cleanly? Everything I try has undesirable limitations. 
related:
What specifically is the goal of the parent type?
Is it just inheriting shared fields so you don’t have to create one in Website Project and one Brochure Project?
This topic (or at least ones quite like it) has come up before and I think you’re right that at the moment, there is no clean way to model this in Fibery 
I feel it can be viewed in a couple of ways:
…and maybe other concepts.
Personally, I feel like being able to control the visibility of fields based on the value of another field, would be a simple way to achieve the second model of behaviour.
It’s not as elegant as true inheritance (and there are issues about what happens to data in fields if/when those fields become ‘invisible’) but I get the feeling that it might be easier to grasp for a lot of users.
Also, being able to hide fields will become a necessity for large workspaces where the entity view just becomes too cluttered.
The goal is to make the schema/DB structure as clean as possible; i.e., no duplication of fields, and no extraneous fields. (see Database Normalization)
So e.g.:
So far our advice is to denormalize types and duplicate all you need if you have very different Types and there are many of them.
If there are 2-3 sub-types and not so many unique fields, it may be wise to just use a single Type with few extra-fields.
To be honest, I don’t think we’ll add Types inheritance in Fibery, since it is a very complex thing (and conceptually as well). However, some integrity could be maintained via automations in future. Still we’ll keep this idea open and collect feedback.
@mdubakov, Can we expect to get something like hiding certain fields in Entity Views, based on the value of a Single-Select field?
Our original goal is to show/hide fields per Type. Even if we add this (quite complex) logic, still these fields will be available in other Views, like board, table, etc.
We’ll think about this problem.
I think it’s not a problem if all fields are always available in all other Views (besides Entity Views), because we already have the ability to customize those views and exclude certain fields.
But this ability would be very useful in Entity Views - if we could conditionally display Entity View fields, customized for each entity, based on the value of a single-select field, that would be a good solution to this issue.
Perhaps we could have the ability to add to each field in a Type, a formula, to determine for each entity, whether the field should visible in its Entity View.
Yes, I agree with that. You suggest allowing users to create rules and define what should be visible, this is a quite complex feature and it should be justified by several important cases to be implemented. I can imagine we can go with Type Templates, imagine that various meetings or various features will have a different set of pre-defined values in some fields (and field visibility can be close to that). So far I think we should consider this for Templates.
Perhaps there is an easy win, in the short term, whereby fields can be grouped, and then shown on the entity card on different tabbed pages, so that there would be a tab for ‘Projects’, a tab for ‘Website’, a tab for ‘Brochure’ etc.
Any fields that are relevant for all project types could live in the first tab page group, and those only relevant for meetings on the second tab, and so on.
@mdubakov, the use case is to achieve a useful facsimile of polymorphic/hierarchical types. Is this not enough?
“Type Templates” sounds like a way to pre-fill some field values. If it also allows some fields to be hidden from entity view, that would certainly work. 
But how is the template chosen/controlled? Is it dynamic, based on the value of an entity field (a rule)? Or is it manually chosen? If the latter, will it be possible to change the “current” template for an entity (i.e., modify its effective type)? It would be preferable if it was dynamic.
Indeed. I made similar observations when I discovered Ninox some time ago:
Also some related discussion here: