Django model per table vs model per select

I am working with Django for a while and now that my "tree" and whole DB is filled with data (note: existing database), I was wondering if the "one model per table" is really better at this point than "one model per select".

I have got one table - objtree. This is the place where I have all nodes (brands, categories, tags, etc.) stored. As you can imagine it is heavily used in my administration. Today I had to add another foreign key for another table, but I have already 2 Foreign keys there. The problem is that I use this model for almost everything, BUT the foreign keys are used rarely, not to mention the third one that would be used this one time. Since each of these tables have 20k+ (minimum) rows and the foreign keys are used rarely, I wonder if it wouldnt be better to use "one model class per select" - speed wise.

Would this approach affect the speed at all? So far it worked fine for me (model per table), but isnt that kind of an overkill for such large DB?

Any opinion is appreciated.

Regards

Edit:

Here is the model. The 3 foreign keys are needed rarely, but as it is now, they are selected anyway, even if I dont need them (maybe there is an easy way to specify which of them I dont want to use when doing e.g. Model.objects.all()).

So the question is if it would be better to have lets say 3 models, where I would use the foreign keys respectively. Would that affect the speed? Or is bad approach? Maybe I am doing something wrong, I dont know.

class Objtree(models.Model):
  node_id = models.AutoField(
    primary_key = True
  )
  type_id = models.IntegerField()
  parent_id = models.IntegerField()
  sort_order = models.IntegerField(
    null = True, 
    blank = True
  )
  name = models.CharField(
    unique = True, 
    max_length = 255, 
    blank = True
  )
  lft = models.IntegerField()
  rgt = models.IntegerField()
  depth = models.Inte开发者_JS百科gerField()
  added_on = models.DateTimeField()
  updated_on = models.DateTimeField()
  status = models.IntegerField()
  point_to = models.IntegerField(
    null = True, 
    blank = True
  )
  node = models.ForeignKey(
    'Objtree_labels', 
    verbose_name = 'Objtree_labels', 
    to_field = 'node_id'
  )
  specs = models.ForeignKey(
    'OptionSpecs', 
    verbose_name = 'OptionSpecs', 
    db_column = 'node_id', 
    null = True, 
    blank = True
  )
  ct = models.ForeignKey(
    'CategoryTemplate',
    verbose_name = 'CategoryTemplate',
    db_column = 'node_id',
    to_field = 'group_id',
    null = True,
    blank = True
  )

---

I was wondering if the "one model per table" is really better at this point than "one model per select".

What is "model per select"? It sounds like your model is wrong.

The problem is that I use this model for almost everything, BUT the foreign keys are used rarely, not to mention the third one that would be used this one time.

What are you doing? This sounds like you're not doing the database modeling part of the job correctly. It sounds -- from this quick description -- like you're throwing attributes at models in a haphazard way.

There's no sensible alternative to "model per table". The questions you should be asking are "What am I modeling?" "What is this real-world object?" And "What is the relational database description of this thing?"

---

if it would be better to have lets say 3 models, where I would use the foreign keys respectively?

Three models means three copies of the tree structure, each with just one foreign key.

The essential questions, however, still remain.

• What is this? Are these three separate things? Are these three aspects of one thing? These are not technical questions, but reality questions. Don't fret over performance. Fret over modeling reality with a great deal of fidelity.

• 'Objtree_labels', 'OptionSpecs', 'CategoryTemplate' -- what real-world objects are these? Labels -- usually don't exist in the real world. Option specs may be something tangible. A category template doesn't sound like a real thing.

Would that affect the speed?

Never. One table with lots of foreign keys and three tables with one foreign key each will be largely indistinguishable in speed. Unless, of course, you are regularly having to match values between separate tables, then the "join" among separate tables will incur some cost.

But if the three values are truly independent -- three separate things -- they must be in separate tables to reflect the fact that they are different kinds of things.