Comments on: Hitting the Database Less: Quick and Dirty Strategies for Database Efficiency http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/ The personal blog of Brandon Savage. Contains entries of a personal and professional nature focusing on PHP, Apple, LAMP, MySQL and Washington, DC. Thu, 29 Jul 2010 11:09:38 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Brandon Savage http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/#comment-1093 Brandon Savage Mon, 07 Sep 2009 18:36:32 +0000 http://dev.brandonsavage.net/?p=86#comment-1093 To me, a long table has lots of rows. A large table can have lots of rows, or each row could be exceptionally large. For example, if you're storing files in the database as blobs, you could have a large table with just a few rows. Likewise, if you have a table of users that contains 35 million rows, that's too much. To me, a long table has lots of rows. A large table can have lots of rows, or each row could be exceptionally large.

For example, if you’re storing files in the database as blobs, you could have a large table with just a few rows. Likewise, if you have a table of users that contains 35 million rows, that’s too much.

]]> By: itchy http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/#comment-1090 itchy Sun, 06 Sep 2009 23:10:45 +0000 http://dev.brandonsavage.net/?p=86#comment-1090 what's the difference between a large table and a long table? what’s the difference between a large table and a long table?

]]> By: Scaling Up: Reducing Drag, Increasing Lift | BrandonSavage.net http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/#comment-63 Scaling Up: Reducing Drag, Increasing Lift | BrandonSavage.net Tue, 24 Feb 2009 16:12:27 +0000 http://dev.brandonsavage.net/?p=86#comment-63 [...] are a number of strategies for hitting the database more efficiently. One that I recommend is caching - either file-based or [...] [...] are a number of strategies for hitting the database more efficiently. One that I recommend is caching – either file-based or [...]

]]> By: Brandon Savage http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/#comment-370 Brandon Savage Tue, 18 Nov 2008 05:28:29 +0000 http://dev.brandonsavage.net/?p=86#comment-370 Jaik, here's what I do know: Jay Pipes who works for MySQL recommends in his Join-Fu talk (http://jpipes.com/index.php?/archives/260-Slides-from-Drunken-Query-Master-and-Join-fu-Talks-at-ZendCon.html) that you be careful when picking your data types. In his slides, he indicates that you should use TEXT sparingly, and BLOB VERY sparingly. He also notes that the smaller your records, the more you can fit into a single page on the disk, and the faster your scans will be. Just because you're not selecting on a particular record doesn't mean that adding on that data doesn't hinder performance. He also recommends splitting up large tables into smaller ones, presumably for the same reason, and partitioning long tables into shorter ones. I'm not an expert in MySQL (Jay Pipes works for MySQL), so I recommend if you want to learn more you visit his website at http://jpipes.com/ and take a look at what he has to say. Jaik, here’s what I do know:

Jay Pipes who works for MySQL recommends in his Join-Fu talk (http://jpipes.com/index.php?/archives/260-Slides-from-Drunken-Query-Master-and-Join-fu-Talks-at-ZendCon.html) that you be careful when picking your data types.

In his slides, he indicates that you should use TEXT sparingly, and BLOB VERY sparingly. He also notes that the smaller your records, the more you can fit into a single page on the disk, and the faster your scans will be. Just because you’re not selecting on a particular record doesn’t mean that adding on that data doesn’t hinder performance.

He also recommends splitting up large tables into smaller ones, presumably for the same reason, and partitioning long tables into shorter ones.

I’m not an expert in MySQL (Jay Pipes works for MySQL), so I recommend if you want to learn more you visit his website at http://jpipes.com/ and take a look at what he has to say.

]]> By: Jaik http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/#comment-369 Jaik Tue, 18 Nov 2008 04:42:42 +0000 http://dev.brandonsavage.net/?p=86#comment-369 Could you explain point 4, I didn't think have large data fields affected performance unless they were being selected or used elsewhere in the query? Could you explain point 4, I didn’t think have large data fields affected performance unless they were being selected or used elsewhere in the query?

]]> By: omerida http://www.brandonsavage.net/hitting-the-database-less-quick-and-dirty-strategies-for-database-efficiency/#comment-368 omerida Mon, 17 Nov 2008 14:22:01 +0000 http://dev.brandonsavage.net/?p=86#comment-368 Excellent tips - one I would add from my experience, is to do any intense data processing outside of the web request, for example via cron scripts. If you need to count/summarize/average, from a large data set to generate reports, consider making those calculations and then saving them to a summary data table. Your web script simply formats the summary data for display. Excellent tips – one I would add from my experience, is to do any intense data processing outside of the web request, for example via cron scripts. If you need to count/summarize/average, from a large data set to generate reports, consider making those calculations and then saving them to a summary data table. Your web script simply formats the summary data for display.

]]>