4 ms·
This seems to go against YAGNI, and I'm not sure I agree it's good advice. A system I worked on recently modeled users as potentially belonging to more than on
by dmazzoni 3y ago
This seems to go against YAGNI, and I'm not sure I agree it's good advice.
A system I worked on recently modeled users as potentially belonging to more than one organization, even though there wasn't a good use case for that and there wasn't any plan for how it should work if implemented. It made all of the code to get the organization from a user more complex than it should have been.
Another system I worked on had a view hierarchy that allowed a view to have more than one parent, even though there was absolutely no support anywhere in the system for a view to actually have multiple parents in practice; if you tried, everything would just crash or get into an endless loop. The only use case suggested in comments was that a cell could be a child of both a row and column in a grid, but that was just theoretical - it didn't allow for any functionality that couldn't be achieved some other way.
If you know how something should behave with a one-to-many relationship, and you know it's a use case that you might want to support, then yes, you should model it that way.
But, if you don't know how it would behave, and you can't think of a use case, then don't overcomplicate things.
Yes, a person can have more than one pet. But a person can only have one head, so why complicate things when there's no known use case for a two-headed person?
- floppydiskette 3y agoIt sounds like the article is mostly advocating for a “one parent to many children” scenario, where the first organizations/users example you gave would be “many to many”, and your second view example is “one child to many parents”.
- perilunar 3y ago> But a person can only have one head Not so: https://en.wikipedia.org/wiki/Polycephaly https://en.wikipedia.org/wiki/Polycephaly
- jj999 3y agoAre you sure it's one person with two heads and not two sharing a body?
- simonw 3y agoI coined the term PAGNI - Probably Are Gonna Need Its - for exactly this kind of thing. There are exceptions to YAGNI which are things which don't cost much to add at the start of the project but are really expensive to add later on. https://simonwillison.net/2021/Jul/1/pagnis/ https://simonwillison.net/2021/Jul/1/pagnis/ I do agree with you that many-to-many for everything isn't always the right choice though. It's a pretty tough call to make. I've had plenty of conversations with product people where I've said "Are you absolutely SURE that the user will only ever have ONE of this thing? There are no possible situations where they might have more than one?" and had the answer "Well, OK there's this one rare case where they might need more than one... but it's hardly ever going to happen..."