On Mar 3, 2010, at 11:26 AM, mk wrote:
D'Arcy J.M. Cain wrote:
I keep seeing this statement but nothing to back it up. I have
created
many apps that run on Python with a PostgreSQL database with a fully
normalized schema and I can assure you that database joins were never
my problem unless I made a badly constructed query or left off a
critical index.
I too have done that (Python/PGSQL), even adding a complicated layer
of SQLAlchemy on top of it and have not had issue with this: when I
profiled one of my apps, it turned out that it spent most of its
computation time... rendering HTML. Completely unexpected: I
expected DB to be bottleneck (although it might be that with huge
datasets this might change).
Having said that, re evidence that joins are bad: from what I've
*heard* about Hibernate in Java from people who used it (I haven't
used Hibernate apart from "hello world"), in case of complicated
object hierarchies it supposedly generates a lot of JOINs and that
supposedly kills DB performance.
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.
My $.02
Philip
--
http://mail.python.org/mailman/listinfo/python-list
