Jay Pipes of MySQL AB and co-author of Pro MySQL, comes to Atlanta this month to present “Join-Fu: The Art of SQL.”

I’ve seen Pipes speak before, and his presentation was incredibly informative. If you do a lot of development with MySQL, you should definitely attend.

Related:

• Jay Pipes’s Slides for Join-Fu: The Art of SQL (I and II) (I do not know whether this will be the same talk as the one Pipes will give next month.)
• RSS for Tech Events

PHP supports more than a dozen database setups, including the SQLite library bundled with PHP 5. That’s a lot of databases, and each one has its own connection syntax and server-specific functions.

So what happens when you want to be able to swap one database for another? You turn to an abstraction library, such as PDO.

In Learning PHP Data Objects, Dennis Popel takes you through the process of building an application using PDO with MySQL and SQLite.

Aimed squarely at PHP developers who are new to PDO, Popel covers how to make connections, handle errors, and use prepared statements with PDO. He also discusses transactions, MVC development, and the appropriateness of using PDO versus other abstraction libraries.

Where Learning PHP Data Objects shines, however is in its code examples. They are easy to follow, and Popel smartly alerts readers to potential gotchas in developing the sample application.

The book assumes an understanding of OOPHP — necessary because PDO is entirely object-oriented. To get the most out of it, you should be familiar with object-oriented principles and syntax. While Appendix A does give readers a quick overview of OOPHP, for a more thorough treatment, you’ll need to look elsewhere.

It’s a solid, though not quite perfect book. For example, Popel only sort-of mentions a potentially huge gotcha: when you may need to specify a unix_socket parameter in the connection string. It’s a problem I think would be common enough and confusing enough to discuss and demonstrate. I also think Popel could have been a bit clearer about when and why to use PDOStatement->closeCursor().

Those are minor quibbles however, easily solved by consulting the documentation or doing a Google search. Overall, this book is nice introduction to the whys and hows of using PDO to develop database driven applications.

Jay Pipes is the Community Relations Manager, North America for MySQL, Inc. This was a three-hour tutorial about ways to fine-tune your MySQL queries.

This is part one of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Indexes

• Gives you a sorted order that allows you to find things quickly.
• Indexes speed up select or read statements.
• Indexes slow down writing to the database because MySQL not only has to write the record, but also has to write the index.

The kind of indexes available and their efficiency depends on the type of storage engine you choose. Keep your indexes slim on write-intensive applications.

Types of storage engines

Choose your table’s storage engine type based on the type of information it holds, and the function for which you will use the table. Can mix table types in the same database.

MyISAM

• Unclustered data storage
• Good insert performance and good with concurrent inserts
• Small foot print
• B-tree, r-tree and FULLTEXT indexing; Can use for spatial calculations, such as ZIP codes
• Poor concurrent update and delete performance
• No foreign key support; You can use a foreign key, but relational integrity is not guaranteed. (Forthcoming in version 5.2)
• No transactions available

Good for warehousing data, logging data and auditing data.

InnoDB

Good for when you need a lot of concurrent updates and will be looking data up by ID. Good for online transaction processing.

• NO FULLTEXT indexing or spacial data (r-tree indexes).
• Large memory usage and a large data footprint.
• Full transactional support
• Support for foreign keys
• Be sure to set a primary key, and use the smallest possible key (INT not BIGINT). If you don’t InnoDB will create it’s own super-integer index. Because of the way InnoDB handles indexes, this is not desirable.

Archive

Good for archiving, audit logging, and distributable media (for example, applications that you don’t want the user to be able to modify).

• Quick inserts and table scans
• Read-only
• Zlib compression
• No indexes allowed
• No foreign key support

Memory / HEAP

Great for temporary tables, session data, calculation tables, or information that will be requested frequently.

• Very, very fast selects because it’s all stored in memory
• Supports hash or b-tree indexes
• Data is gone on reboot, but you can get around this with init_file or my.cnf/my.ini.
• Limited by amount of memory available on the server

Can combine engine types within the database to take advantage of each storage engine’s strengths.