On Thu, 2006-07-06 at 23:01 -0700, GrumpySimon wrote: > Sure, but it's very common (and good database etiquette) to want to get > a subset of fields from a set of rows and leave out unnecessary > information. This is really quite important when it comes to things > like blob fields.
If you have very large fields that you are not going to want to retrieve all the time and which are sufficiently large that retrieving them impacts performance, then it is poor design to have them in your frequently accessed table. A database server cannot retrieve "part of a row" from disk: it reads the whole row in and then discards the values it does not need to return to a client, so you are already paying the greater penalty in disk seeks and reads just getting the data into memory in the first place here; transmitting back to the database's client is not your real problem. Very wide tables where you typically don't need to access the whole row have bad performance at large scales. The normal solution here, that also works in Django, not surprisingly, is to move the large, infrequently accessed field off to its own table and refer to it by a key. A OneToOneField or ForeignKey will do the trick. Then you read the reference integer all the time (essentially free) and only read the large data in when you explicitly access it. Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
