0

Let's say I have Cars, CarTypes, and their BuildDates like this: 

class Car(db.models):
    licence_name = models.CharField(max_length=64)
    car_type = models.ForeignKey(Type)

class Type(db.models):
    name = models.CharField(max_length=64)
    build_during = models.ForeignKey(BuildDate)   

class BuildDate(db.models):
    begin = models.DateField(null=True)
    end = models.DateField(null=True)

    class Meta(object):
        unique_together = (('begin', 'end'),)

I want to have the BuildDates in a seperate table such I can do faster queries and other stuff with Django-external tools.

Since BuildDates are unique but shared between CarTypes, I want to make sure this: If the BuildDate d0 of one CarType t1 is changed, the other CarTypes are not affected and they still share the identical BuildDate d0 – but not with t1 which now has d1. I believe it is necessary to create a new BuildDate d1 for that CarType t1. Is there a recommended or recommendable way to do this?

AME
  • 2,499
  • 5
  • 29
  • 45
  • How is having a distinct model supposed to yield faster queries ? Care to share a couple use cases ? – bruno desthuilliers Sep 01 '14 at 13:45
  • SELECT cards_car.id FROM cars_car, cars_type, cars_builddate WHERE cars_builddate.begin >= x and cards_builddate.end <= y AND cars_car.type==cars_type.id AND cars_type.build_during = cars_builddates.id – AME Sep 01 '14 at 14:52
  • Err... Are you **really** sure that adding an inner join will **really** make your query faster ? If yes I'd like to know which SQL database you're using. As far as I'm concerned I've never seen such a result from adding a join, quite on the contrary - in fact there's even a little game named "denormalization" where you trade atomicity for performance by getting rid of joins... – bruno desthuilliers Sep 01 '14 at 15:00
  • :( http://stackoverflow.com/questions/4394183/should-not-olap-database-be-denormalized-for-reading-performance/4731664#4731664 – AME Sep 01 '14 at 15:25
  • Yes, there are guys like this in the relational DB world that really think that any schema should be in "6th normal form" ("the row consists of a Primary Key, and at most, one non-key column") xD. FWIW such a guy would send you in jail for using an "ORM", and even for writing any kind of domain logic outside the database. Now you can choose to go this way, or just do what any sane developper would do here: get rid of the `BuildDate` model and store start / end dates in your `Type` model. You'll save yourself and the world a lot of pain. – bruno desthuilliers Sep 01 '14 at 15:44
  • That's how it was before. Query time too slow. Thank you nevertheless. – AME Sep 02 '14 at 06:52

1 Answers1

1

Use "editable" attribute. When you set "False", element will not be shown in the admin, that is, you can't change its value.

e.g.

licence_name = models.CharField(max_length=64, editable=False)

AndiS
  • 63
  • 6