The more generic is yr model, the more you will find these.
and of course these join tables can grow exponentially !
What you can do is add extra fields to navigate faster or allow
partitioning of the table (it helps but not in all circumstances)

IMHO
Unless you are working for Yahoo/Google/FB/... I would not advise to
generate tables behind the scene.
Should you HAVE to do those ... use a queuing mechanism instead of
Stored Procs... it scales +/- the same (CPU-memory-... wise) BUT it is
much more robust in case of problems/failures/...
If there are no cascading delete... make sure you have clean up stored
procs to have the non-meaningfull data being purged.

I don't understand what you mean with proble 3 !

\T,


On Aug 19, 6:15 am, v0idnull <v0idn...@gmail.com> wrote:
> I asked a while back about having generic relations and someone pointed
> me tohttp://docs.djangoproject.com/en/1.2/ref/contrib/contenttypes/#generi...
>
> This wasn't what I was looking for.
>
> What I was looking for is this model I made:
>
> class Relationship(models.Model):
>
>      id = fields.UUID(auto_add=True,primary_key=True, unique=True)
>      created_by = fields.UUID(db_index=True,null=True,blank=True)
>      created_on = models.DateField(auto_now=False,auto_now_add=True)
>      modfied_on = models.DateField(auto_now=True,auto_now_add=False)
>      title = models.CharField(max_length=255)
>
>      source_id = fields.UUID(db_index=True)
>      source_app_label = models.CharField(db_index=True,max_length=255)
>      source_model = models.CharField(db_index=True,max_length=255)
>      destination_id = fields.UUID(db_index=True)
>      destination_app_label = models.CharField(db_index=True,max_length=255)
>      destination_model = models.CharField(db_index=True,max_length=255)
>
>      description = models.TextField(null=True,blank=True)
>      type =
> models.CharField(max_length=64,null=True,blank=True,db_index=True)
>      priority = models.PositiveIntegerField()
>
> Then an abstract model that all my "digital assets (ie: images,
> articles, comments, audio files, video files, etc)" extend contain these
> methods:
>
>      def getType(self):
>          if (self._type == None):
>              self._type = ContentType.objects.get_for_model(self)
>          return self._type
>
>      def relatedTo(self):
>          rels = Relationship.objects
>          return
> rels.filter(source_app_label=self.getType().app_label).filter(source_model=self.getType().model).filter(source_id=self.id)
>
>      def addRelation(self,destModel,type=None,priority=0):
>          rel = Relationship()
>          rel.destination_app_label = destModel._getType().app_label
>          rel.destination_model = destModel.getType().model
>          rel.destination_id = destModel.id
>          rel.source_app_label = self.getType().app_label
>          rel.source_model = self.getType().model
>          rel.source_id = self.id
>          rel.type = type
>          rel.priority = priority
>          rel.save()
>
> This APPEARS to do what I want it to do:
>
> 1) it describes the relationship with some meta data
> 2) it allows me to use filters to find relationships
> 3) it's not a constraint, so no cascading deletes
> 4) it's many-to-many. Any asset can be related to any other asset. It
> seems GenericForeignKey can do: "this tag is related to this bookmark",
> but it can't do "this bookmark, this article, and this photo, have these
> tags related to them"
>
> However, I see problems:
>
> 1) It's a single point of failure!!
> 2) This is a db table that can grow very quickly
> 3) I lose other functionality, like being able to quickly get an
> instance of the referenced object
>
> So I wonder if anyone has any advice. I'm new to Python and don't fully
> understand it's limitations, so I might not be thinking big enough (ie:
> I could be having behind-the-scenes functionality that automatically
> creates tables for relationships between specific model classes, but is
> that performant?).
>
> Perhaps even an existing open source project to handle these kinds of
> relationships.
>
> Thank you

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Reply via email to