On Mar 3, 2010, at 3:58 PM, mk wrote:
Philip Semanchuk wrote:
So there *may* be some evidence that joins are indeed bad in
practice. If someone has smth specific/interesting on the subject,
please post.
It's an unprovable assertion, or a meaningless one depending on how
one defines the terms. You could also say "there *may* be some
evidence that Python lists are bad in practice". Python lists and
SQL JOINs are like any part of a language or toolkit. They're good
tools for solving certain classes of problems. They can also be
misapplied to problems that they're not so good at. Sometimes
they're a performance bottleneck, even when solving the problems
for which they're best. Sometimes the best way to solve a
performance bottleneck is to redesign your app/system so you don't
need to solve that kind of problem anymore (hence the join-less
databases). Other times, the cure is worse than the disease and
you're better off throwing hardware at the problem.
Look, I completely agree with what you're saying, but: that doesn't
change the possibility that joins may be expensive in comparison to
other SQL operations. This is the phrase I should have used perhaps;
'expensive in comparison with other SQL operations' instead of 'bad'.
Well OK, but that's a very different argument. Yes, joins can be
expensive. They're often still the best option, though. The first step
people usually take to get away from joins is denormalization which
can improve SELECT performance at the expense of slowing down INSERTs,
UPDATEs, and DELETEs, not to mention complicating one's code and data
model. Is that a worthwhile trade? Depends on the application. As I
said, sometimes the cure is worse than the disease.
Don't worry about joins until you know they're a problem. As Knuth
said, premature optimization is the root of all evil.
Good luck
Philip
PS - Looks like you're using Postgres -- excellent choice. I miss
using it.
--
http://mail.python.org/mailman/listinfo/python-list
