2 ms·

I’m curious, you admit that “generally use inner joins” is a leaky abstraction, because there are corner cases where left joins are needed. Why not just use th

I’m curious, you admit that “generally use inner joins” is a leaky abstraction, because there are corner cases where left joins are needed. Why not just use the non-leaky abstraction “always use left joins” and then an entire class of errors and discussions can be avoided? Increasingly as I get older, I see the job of architect as “have conversations for the last time” so that devs can focus their “conversation quota” on the things that can’t be avoided, thus moving faster.

bob1029 5y ago
> Why not just use the non-leaky abstraction “always use left joins” and then an entire class of errors and discussions can be avoided? This is why I am happy to stay out of the way of others. If I were to impose a strict "always use left joins", there would be a different problem of similar flavor. There are some team members who prefer to be more precise with the intent of their joins, and others who prefer to be more defensive. As long as the end result is as desired, I am happy and the customer is happy. What I focus on the most throughout is making sure that any non-malicious query can run without worrying too much about performance. We scope our data sets so that even recursive table scan scenarios can complete within seconds. This eliminates the most onerous class of discussions in my experience - those of premature optimization.