Daniel Fetchinson wrote:
<cut>
In an relational database setting you would have a table for artists,
a table for cd's and a table for songs and a table for comments where
people can comment on songs. All of this with obvious foreign keys.
Now you want to display on your website the total number of cd's, the
total number of songs and the total number of comments because that
looks very cool on top of every page: 1242342 cd's and 134242342342
songs and 284284728347284728 comments!
Okay, so you need to issue a query with joins in your relational db.
Or in another query, you want to select all comments of an artist,
meaning all comments that were comments on a song belonging to cd's of
a given artist. This would also involve joins.
How would I do these queries if I can't have joins or in other words
how would I lay out my data storage?
Thanks by the way for your help and replies,
Daniel
What actually is happening here is that feature x which is usually in an
abstraction layer (like a RDBM) is not available to you. Which means you
have to write code which does the same but on your side of the code.
I played a bit around with the GAE some time ago and designed the
storage of all data in an sort of EAV model
(http://en.wikipedia.org/wiki/Entity-Attribute-Value_model)
The abstraction layer had all my meta code, counting stuff up was a
matter of creating a list of id's from one section and with that list
selecting the appropriate records on the other section, then count up
the number of results or use the result again, it is very likely you
have to do quite a lot of queries before you get the result.
So in other words, just lay out the data which makes the most sense to
you, the pain of recreating SQL like logic is there no matter what
layout you choose.
--
mph
--
http://mail.python.org/mailman/listinfo/python-list
