large db question about no joins

Aaron Brady castironpi at
Thu Apr 16 21:20:11 CEST 2009

On Apr 16, 1:45 pm, Daniel Fetchinson <fetchin... at>
> [off but interesting topic]
> Hi folks, I've come across many times the claim that 'joins are bad'
> for large databases because they don't scale. Okay, makes sense, we
> agree. But what I don't get, although I watched a couple of online
> videos on this topic (one by the creator of flickr who gave a talk at
> djangoconf and another one by a dev guy from facebook, I think the
> links were posted here too) is how do people solve most basic problems
> without joins? I guess the whole database layout has to be designed
> with this in mind but suppose I have the following layout, how would I
> redesign it so that I can have the same functionalities?
> Let's say I have a table called zoo, another one called cage, another
> one called animal and another one called leg. Each animal has some
> number of legs, each cage has animals in it and each zoo has a number
> of cages in it. Obviously these are represented by foreign keys. If I
> need the total number of animals in a zoo, or the total number of legs
> in the zoo I would use a query with join(s).
> What would be the corresponding database layout that would scale and I
> could get the total number of legs in the zoo or total number of
> animals in the zoo without join(s)?
> Cheers,
> Daniel
> [/off but interesting topic]
> --
> Psss, psss, put it down! -

for cage in zoo:
  for animal in cage:
    for leg in animal:
      count+= 1


I think that relational algebra wasn't designed to be able to
sacrifice joins.

Wait a second., how many legs in the zoo??

More information about the Python-list mailing list