Something like this for your models:
class User(meta.Model):
name = meta.CharField()
class Website(meta.Model):
url = meta.CharField()
class Tag(meta.Model):
name = meta.CharField()
class Tagged(meta.Model):
user = meta.ForeignKey(User)
site = meta.ForeignKey(Site)
tag = meta.ForeignKey(Tag)
And that's it... now some magic:
- All tag names for http://www.google.com
tagged_list = taggeds.get_list(site__url__exact = 'http://www.google.com')
for tag in tagged_list:
print tag.name
- All tags for user 'inerte' on http://www.google.com:
tagged_list = taggeds.get_list(site__url__exact =
'http://www.google.com', user__name__exact = 'inerte')
- All users that tagged http://www.google.com with 'search':
tagged_list = taggeds.get_list(site__url__exact =
'http://www.google.com', tag__name__exact = 'search')
You get the idea :)
The 'id' column is implicit here: It exists, but we didn't had to
specify. A "Website" object will have the "id" and "url" parameters,
and it doesn't matter much what you will use for __exact, as long as
they are unique, I guess...
What's a highly normalized database and why did you get the
impression that isn't Django focus? If you pass the 'selected_related
= True' parameter to get_list() you will see some really complicated
queries being built to aggregate all the possible data, avoiding many
re-queries (which I probably should have done on the first get_list()
example).
Btw, you should really stop thinking about the database design
before writing your models with Django. Code how your data is
structured, its relationships, let Django figure out how to select
them, and only fix if it brakes.
On 1/31/06, kggroups <[EMAIL PROTECTED]> wrote:
>
> I could also foresee situations where I would use a key on 3-tuples,
> etc. How well is django equipped to handle relationships like this?
>
>
--
Julio Nobrega - http://www.inerciasensorial.com.br
