[zelphirkalt]

There are multiple things that come to mind, that you can look into, perhaps find a good explanatory text or video about:

ERM - Entity Relationship Model

1., 2., and 3. normal form for relational databases (usefule to avoid redundancy and designing it, so that it can be extended later, and avoiding pitfalls like non atomic values).

User stories and thinking about, whether they can be comfortably implemented using the proposed model.

SQL - for understanding what might happen behind the ORM (Object Relational Mapper).

Those things are however not Django specific, which might be the reason, why one might struggle with them, if one is just starting out coding with Django. Django tutorials will usually not cover these. However for a personal project, maybe a not perfect database design is OK as well. Do not despair because of it.

[35mm]

Thanks! I’m trying to define a product model which can have multiple types, each of which has required attributes.

For example a solar panel has to have a peak output, but no energy storage. But a battery type of product is required to have a storage capacity.

[zelphirkalt]

Probably the whole picture of how you want to use the data in your database needs to be considered to judge this properly. There are "escape hatches" like having a separate entity, which is called something like "ProductAttribute", with a foreign key being the actual "Product". The Product would still have attributes, which every product has, lets say a name, a product id, a creation date, etc., while ProductAttribute could contain any other attribute, not relevant for all products.

Why is this an "escape hatch"? Well, if you want to process that data later, it would most likely be very convenient, if you had all product attributes as columns, instead of having them as rows in another table. One would then have to translate back to the usual form of having them as columns. It is possible, but annoying. However, if you never need to analyze the data like that, then storing in this kind of extra table might solve all your use cases. It is ultimately a trade-off between safety or type strictness and flexibility (being able to add arbitrary attributes without having to change the schema).

Another, but in my opinion quite bad, solution is, to have loads of empty columns for future attributes. But it is really a terrible solution, running contrary to any good database design.