<br><br><div class="gmail_quote">On Tue, Jul 19, 2011 at 5:53 AM, David Berthelot <span dir="ltr"><<a href="mailto:david.berthelot@gmail.com">david.berthelot@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>So I generally wouldn't consider the database speed independent of the framework as long as the framework does some automatic database request generation and type handling. This became particularly obvious as the database grew bigger and the framework became slower.<br>
</div></div></blockquote><div><br>I am a speed maniac, and i like apps to be fast, i am ready to sacrifice feature set for good speed; or rather, present the feature set with a few more clicks - i.e, if you are showing an item on a page, then i would generally like to show everything related to that item in a single page; but showing all the related items(which can cause more SQLs and HTTP requests) can cause a probable slowdown, i would rather show links which would link to the related items (sometimes this approach also leads to a lesser cluttered UI - but again, the number of clicks that the user has to do is more [some UI experts rate an app based on the number of clicks that a user has to to achieve an end result]).<br>
<br>Having said that, its very important to profile an app - in a django app that i was developing in my fun time, i happened to see that there were 40+ queries on a single page, using DDT i was able to diagnose the SQLs being fired, and was able reduce this to just 6 - and out of these 6, 1 sql is for hitting the msgs tbl and the other 1 is for checking if the user is logged in(unavoidable).<br>
<br>I truly believe in the fact that "performance is a feature" [ <a href="http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html">1</a> ]. Also, IMHO, if you can move bulk of the business logic to SQLs (in most apps you have to use SQLs), then you can make your code less cluttered and also easy to maintain. For eg. in this case [ <a href="http://groups.google.com/group/django-users/browse_thread/thread/b2b3aea021c9b7d0/52d1aa80ea7a2dd5">2</a> ], i moved the filtering to the SQLs; and also even in here, i was firing 3 queries earlier and was doing some iterations (pain!).<br>
<br>To explain [2], i have 2 types of users: employees and general-users(non-emps). I needed to get all items for a given employee or customer(non-emp); if the user happened to be employee then get all items from his org - so you need to iterate over all emps and get respective items for each emp and concatenate the list. If the user was a general-user(non-emp), then simply get his items alone.<br>
<br>items = []<br>if self.is_superorg_user(): #check user type<br> emps = self.get_all_employees() #get all employees<br> if emps:<br> for e in emps: #iterate over the emps<br> p = Items.objects.filter(created_by=e).filter(deleted=False) #get items by THIS emp<br>
if len(p)>0:<br> items.extend(p) #keep concatenating to the orig list<br>else: #non-emp user<br> items = Items.objects.filter(created_by=self)<br><br>Now, all those SQLs for emp users, can be removed and replaced with:<br>
<br>items = []<br>
if self.is_superorg_user(): #check user type<br> items = Items.objects.filter(created_by__employees__org__in=self.employees_set.all().values_list('org'))<br>else:<br> items = Items.objects.filter(created_by=self)<br>
<br>[1] <a href="http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html">http://www.codinghorror.com/blog/2011/06/performance-is-a-feature.html</a><br>[2] <a href="http://groups.google.com/group/django-users/browse_thread/thread/b2b3aea021c9b7d0/52d1aa80ea7a2dd5">http://groups.google.com/group/django-users/browse_thread/thread/b2b3aea021c9b7d0/52d1aa80ea7a2dd5</a><br>
<br>-V<br><a href="http://blizzardzblogs.blogspot.com/">http://blizzardzblogs.blogspot.com/</a><br></div></div>