Forget the ORM for a second. Can someone explain me, on a database level, how would you enforce a Band table to have at least one Musician ?
For me having such a requirement is a non-sense, a Band should be able to exists without Musicians.
I don’t think there is a database schema that can’t be achieved with the ORM, which makes it just perfect enough, because you get perfection not when you have nothing more to add, but when you have nothing more to remove.
Here’s the use case that brought me here 4 years after the start of the conversation:
I am building an application that may be used by many organizations which may want to use some modules of it, but not others.
One of the core modules that all organizations may want to use is “Individual” which is essentially a model representing unique individuals.
Individuals may have phone numbers and email addresses that are unique to them. Or the organization using the app may decide they don’t need email addresses for their use case. In any event, a ForeignKey works great because these days a phone numbers aren’t shared by more than one person, nor are email addresses.
But there is another model used called a “Household”. In legal terms, (typically for Government programs) a Household is not so much an address as it is a unit of habitation by one or more individuals.
An address could in fact have multiple households if for example there were multiple groups of people who didn’t share resources with each other, but all used the same mailbox as would be the case with roommates living in a house, but keeping their own food and separate living areas. So a household is not the same as an address.
Likewise, an address might have people who get mail at it, but there is no Household there as is the case with a P.O. Box, or even a vacation house.
An Individual would always legally be part of exactly one Household. But not all organizations using the app would need to manage any data relating to a household.
At first it seems perfect for a ForeignKey on Individual to Household. But if an organization decided they don’t want to use the Household module of the app, the Individual model would need to be altered to make the app function without households.
As others have pointed out, it’s a semantic problem at least. But in this way it’s also a practical problem due to the need to work the system of modularity around this limitation of the ORM.
Other than this one issue, organizations could easily just add and remove modules as they desired. Those modules with logical dependencies would have to be enabled together.
The Phone model depends on the Individual Model. But the Individual model should not depend on the Household model being enabled.