Domanda

Good afternoon,

I am designing an application and I can't seem to get my head around this problem. My application will have different types of pictures: company, profile, machine, etc... and we are expecting a LOT of pictures. Now, since we will have a lot of different types of pictures, I was thinking of creating a base class called "pictures" in Django, and then create all the subclasses from that. That would give n tables in my database. Hence the querying would be faster since I wouldn't have one giant table with all my pictures, and have to do JOINS on a category table when I want pictures of a certain type.

To do this, I will have to use generic foreign keys in Django. Is that good practice? Is my design a good practice or not? I was told Generic Foreign Keys were not that good of an idea... why?

Thanks!

EDIT: I won't be storing the image per se in the table, just the path within the AWS S3 Bucket!

È stato utile?

Soluzione

Are you sure you want and need your images stored in the database? In many cases, you may be able to get significantly better efficiency by storing the images on the filesystem instead of the database.

store images outside of the db

When you store the images on the filesystem, you can serve them directly from your webserver, or cloud host such as Amazon S3 or content distribution network, or memcached, etc.

metadata

In your own database, good info to store (IMHO) is metadata about the image such as a searchable file name (if your users will be searching that way), pixel dimensions (if you want to search by size or provide image height and width in your HTML), mime content type (if that's useful to you), etc.

For your description of different types of pictures, it depends on what kinds of different information you want to store about each type.

sti or multiple tables?

Are your kinds of images essentially the same? [By kinds, I mean like Company, Profile, Machine, etc.] If so, I would use one table for all of them (the metadata, that is) with an enumerated type field. Depending on your database you can do this with a string name such as "company", "profile", etc. or with an int constant such as 1 for company, 2 for profile, etc. Django has a couple of ways of doing inheritance. The pattern name for this is Single Table Inheritance (STI). I believe Django doesn't support this exactly, yet if you search for it you'll get in the right ballpark for how to implement it.

Are your kinds of images essentially different? If your kinds of images have very different kinds of data, then yes, use separate tables.

As far as I know, the speed difference between using one table with an index vs. separate tables should be similar because in both cases there's essentially one lookup per request to find out the range of image rows. You can benchmark to be sure.

lessons from haystack

Before you write a lick of code, read how Facebook achieved this -- it's a great overview.

http://www.facebook.com/note.php?note_id=76191543919

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top