On Mon, 2009-02-23 at 10:38 -0800, Michael Strickland wrote: > More of a general best practices question for Model design with > respect to query efficiency: > > I'm designing the schema for a newspaper site that will have 2-3 main > types of content: Articles (with a rigid, standardized presentation), > Articles (with heavy HTML customization), and general Content (for > designing custom, special pages from scratch that don't need > individualized templates). > > All three would have many database fields in common (author, category, > tags, etc), but would also require varying numbers of textfields, etc. > > From a page like the front, I need to be able to call the teasers of > any and all of these types of content indiscriminately. For example, > if I wanted a list of three specific Articles on the front, I'd just > make a query that calls up the articles of three specific slugs - one > query, because they're all the same type of content. > > If, however, I wanted two Articles and one Content page to be teased > on the front, am I correct in thinking that I would need to make two > queries if they were separate model types? The other option, of > course, is to make them all one Model, with a selector that determines > what type of content it is, thus only ever needing one query. > > Multiple models means fewer queries, but more columns in the model > than any one type of content uses. My question is which is preferable > in the long run for efficiency: multiple queries, or slimmer models? > > In case it's relevant, the database would have 20,000-50,000 articles > at launch.
The correct answer to these question is always: profile it and see. It doesn't take long to create a couple of samples of each approach and a few tens of thousands of dummy stories. Then try it out on the hardware / database / network that you'll be using. You might well find that multiple database queries are fast enough (which is always the goal, not "as fast as possible", since that's impossible to always achieve). As a general rule, database queries will dominate the request time. It's where the bulk of the work is done. However, database tables with very wide tables (lots of non-text columns) will be slower to retrieve data from that database tables with narrower tables, since multiple disk blocks have to be read for each row, at some point. I would initially go for the clearest possible code and then see if it's fast enough. You can work that out without doing too much work, as mentioned above. Reducing database queries is always a good general goal, however. Regards, 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 django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
