[[Cardinality]] has **always** proven to be one of, if not *the* most important factors impacting the design of any given system. I've experienced time and again the profound changes that something as seemingly simple as changing a `one-to-many` relationship into a `many-to-many` relationship can have. Some of the most fundamental changes to things I've built that have actually had profound performance and quality-of-life impacts was when I changed the cardinality of the components. Cardinality is one of the reasons the [[Hub and Spoke Architecture]] is so nice. You avoid many-to-many relationships by having a central hub. The **one** hub has **many** spokes it relates to. From my recent change to the [[PDW]]: ![[Cardinality-Switch.drawio.png]] Typically zero-to-many relationships I'd think would be *more* complicated - but in this case I'm hoping it will end up meaning there are *fewer* "have-to-have"s and the minutia of the system can be more flexible. Only the top-level [[Broker]] need care about whether or not everything maps together - before I was doing this on a entity-by-entity basis. Driving the logic down that low meant ramifications & rule checks had to be propagated *everywhere*. Also the change allowed me to remove two whole classes from the system. **** ### Source - self ### Related -