3 ms·

I've seen this happen due to system evolution. At first some entity may have a parent record or not. So when you ask for the parent, you either get it, or null.

I've seen this happen due to system evolution. At first some entity may have a parent record or not. So when you ask for the parent, you either get it, or null. But then the system evolves to not be many-to-one, but many-to-many. To avoid breaking old clients, they make it so the only difference is when they return multiple related records, in which case they're given in an array. Thus you now have: null for empty, the record it self if there is only one related, and an array of records if there are more than one related.

lowercased 7y ago
there are still evolutionary justifications which I'm sympathetic to now and then, but mostly not. In many (most?) cases, understanding if something should be one-one or one-many is known up front. Or should be known. We have decades of examples of best practices with many common data structures. Hard coding a customer account to only ever have one address, for example - no. I don't buy that justification - a customer/address thing - for any size company/project - should just be modeled as one-many (at least). It may be slightly more 'work' up front, but that work avoids potentially major breaking changes and work later on. I get countered with "YAGNI" now and then, but after 25+ years of doing this (and, again, decades of examples of your exact use cases already in google ready to learn from), I can usually tell when you ARE going to need it.