large db question about no joins

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


On Apr 16, 1:45 pm, Daniel Fetchinson <fetchin... at googlemail.com>
wrote:
> [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! -http://www.cafepress.com/putitdown

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

</unhelpful>

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