Should I use generic foreign key, and how?

46 views
Skip to first unread message

Aaron Law

unread,
Aug 16, 2014, 3:46:33 PM8/16/14
to django...@googlegroups.com

Hi all,

I have php web programming background, and new to Django. I am helping my brother to build an online system to manage inventory, and I've got a database design & coding problem recently. Needing help!

That is, I have a set of tables of "possible products", "inventory", "suppiler", etc. I want to attach a "comment" to each of them. Therefore, I think I should make a generic "comment" table to hold all the comments of products, inventory, suppiler.

--
possible_products
id: int (pk)
name: varchar
url: varchar
price: decimal
created_at: datetime
updated_at: datetime
--
comments
id: int (pk)
parent_id: int (fk)
content: text
author: int (fk)
table: char (which the table this comment belongs to)
created_at: datetime
updated_at: datatime
--

My problem is, when "possible_products" table is the parent of "comment", then a foreign key of the parent (id number) is stored in the "comment" table in order to link up them.

However, how about the fk of the "inventory" table and the "suppiler" table? It should not be that: I create 2 more columns of "inventory_id" nor "suppiler_id" in "comments" table. (That is, I should not create the 4th column when I want to link up the 4th parent table.)

So, Should I use generic forgien key of Django? (so that, my "comment" table design is right.) And how to use/implement it?

P.S I mainly develop the system in the Admin section of Django.

Regards,
Aaron Law Ho hon
--~--~---------~--~----~------------~-------~--~----~
Free as in Freedom ;-)
--~--~---------~--~----~------------~-------~--~----~

Collin Anderson

unread,
Aug 16, 2014, 6:01:11 PM8/16/14
to django...@googlegroups.com
I think there really are two ways to do it, as you say.

Either use a GenericForeignKey(), or have multiple ForeignKey(null=True, blank=True), each one pointing to a different model. I personally use the multiple foreign keys approach, but this is the case that GenericForeignKey was designed for.

Davide Scatto

unread,
Aug 17, 2014, 3:09:37 AM8/17/14
to django...@googlegroups.com
another way is not to use fk but generic field, where patent_id is a normal integer field. In a custom manager you have to manage the data content in this field with data content in table field to retrieve yr linked record.

Amirouche Boubekki

unread,
Aug 17, 2014, 5:01:19 AM8/17/14
to django...@googlegroups.com
You SHOULD rather create an abstract ProductBase model class with a ManyToMany Field pointing to Comment class and then inherit ProductBase for each specific products.

Most of the time class names are singular.
 
P.S I mainly develop the system in the Admin section of Django.

See also: django polymorphic.

Vladimir Chukharev

unread,
Aug 17, 2014, 5:24:16 AM8/17/14
to django...@googlegroups.com


On Saturday, August 16, 2014 10:46:33 PM UTC+3, Aaron Law wrote:

Hi all,

I have php web programming background, and new to Django. I am helping my brother to build an online system to manage inventory, and I've got a database design & coding problem recently. Needing help!

That is, I have a set of tables of "possible products", "inventory", "suppiler", etc. I want to attach a "comment" to each of them. Therefore, I think I should make a generic "comment" table to hold all the comments of products, inventory, suppiler.

--
possible_products
id: int (pk)
name: varchar
url: varchar
price: decimal
created_at: datetime
updated_at: datetime
--
comments
id: int (pk)
parent_id: int (fk)
content: text
author: int (fk)
table: char (which the table this comment belongs to)
created_at: datetime
updated_at: datatime
--

My problem is, when "possible_products" table is the parent of "comment", then a foreign key of the parent (id number) is stored in the "comment" table in order to link up them. 

However, how about the fk of the "inventory" table and the "suppiler" table? It should not be that: I create 2 more columns of "inventory_id" nor "suppiler_id" in "comments" table. (That is, I should not create the 4th column when I want to link up the 4th parent table.)

You can make the fk to the "possible_products" table. In your particular case, I do not see reasons to take comments into a separate table rather than in the parent table, though this might be just omitted in the description. I do use this style of inheriting tables with connections between them. If you are interested, I have one project in this style in googlecode (early stage yet): labman2.

Note that django docs generally discourage using the involved type on table inheritance. I attribute this discourage to wide use of mysql...

Amirouche Boubekki

unread,
Aug 17, 2014, 2:59:59 PM8/17/14
to django...@googlegroups.com
I second that. I don't understand why you need to make another table to store comments.
 
I do use this style of inheriting tables with connections between them. If you are interested, I have one project in this style in googlecode (early stage yet): labman2.

Note that django docs generally discourage using the involved type on table inheritance. I attribute this discourage to wide use of mysql...


So, Should I use generic forgien key of Django? (so that, my "comment" table design is right.) And how to use/implement it?

P.S I mainly develop the system in the Admin section of Django.

Regards,
Aaron Law Ho hon
--~--~---------~--~----~------------~-------~--~----~
Free as in Freedom ;-)
--~--~---------~--~----~------------~-------~--~----~

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/93d80efa-8ef3-426f-a492-f19222c6a4cc%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages