Even though I'm a total database junkie (and where by that I mean postgresql > mysql :) ), I have to agree with Mike. If you can keep it in the model layer, do that. Once you start putting optimisations into the database layer, you lose a lot of portability between databases: there is no such thing as "standard SQL" for anything other than toy applications. Optimisation tend to be very engine-specific.
However, just remember that those optimisations are possible, and the database is far more reliable for maintaining your invariants than the client is. On Sunday, December 9, 2012 3:30:01 AM UTC-8, Mike Dewhirst wrote: > > > > For the sake of maintainability it might be better to keep all database > manipulation in the model layer rather than split it betweem models and > database. > > > > and, well, that code is part of the > > code base too. > > Which means you need to keep pretty comprehensive documentation if you > are doing database stuff in two areas. > > Personally, I'd keep it all in the django ORM until the project is > mature and requires the final molecule of optimisation. > > Mike > > > > > - Tom > > > >> > >> Derek > >> > >> [1] https://docs.djangoproject.com/en/dev/topics/signals/ > >> > >> On Saturday, 8 December 2012 04:27:50 UTC+2, Chris Cogdon wrote: > >> > >> It's a simple performance vs storage question. > >> > >> Storing a calculatable field also risks it getting out of sync > >> with reality, but if you're doing the query on that _so_ much, > >> then its usualyl worth it. > >> > >> Also, with the right database and a trigger, that's something the > >> database can ensure for you. Ie, a field that the database updates > >> for you. > >> > >> > >> On Friday, December 7, 2012 5:54:37 PM UTC-8, Victor Hooi wrote: > >> > >> Hi, > >> > >> I have a "ranking" field for an item that returns an integer > >> between 1 to 10 based on a number of criteria of each item. > >> > >> My question is - what are the pros and cons of using a model > >> method to return this, versus overriding the save() method and > >> saving it directly into a normal IntegerField on that item? > >> > >> I understand that model methods *won't* let me use them within > >> QuerySet filters on that item - is there any way around that? > >> > >> If I just override the model's save() method to get it > >> recalculate and save that field each time, I can use it within > >> QuerySet filters. Any cons with that approach? > >> > >> What do you guys tend to use in your projects? > >> > >> Cheers, > >> Victor > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "Django users" group. > >> To view this discussion on the web visit > >> https://groups.google.com/d/msg/django-users/-/G7fp5OLkapgJ. > >> To post to this group, send email to > >> django...@googlegroups.com<javascript:>. > > >> To unsubscribe from this group, send email to > >> django-users...@googlegroups.com <javascript:>. > >> For more options, visit this group at > >> http://groups.google.com/group/django-users?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "Django users" group. > > To post to this group, send email to > > django...@googlegroups.com<javascript:>. > > > To unsubscribe from this group, send email to > > django-users...@googlegroups.com <javascript:>. > > For more options, visit this group at > > http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/T32QIqOLH2sJ. To post to this group, send email to django-users@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.
