specializing in digital media technologies

I’ve written 17 books now, counting the various editions, and with every chapter of every book there are decisions to be made about what to discuss and what not to. In a way, publishing becomes an endorsement, although I’m really not an endorsement kind of person. Which is to say that it’s never my intention to sell people on things and I don’t believe that my way is the only way let alone the best way to do something. This may all sound odd, but it’s the approach I have, for better or for worse. (And, truth be told, there are still many times when I feel strongly that X is the way to do something and Y isn’t.) Really, what I feel my job as a writer is, is to take all the information I come across, from reading other sources, from listening to the experts, and from my own experiences, and synthesize it all into a coherent bundle of knowledge. Then, of course, convey that knowledge in an easy-to-follow manner. Anyway, my point in this forward is that there are many things that I haven’t written about and that I don’t personally do but that may be worth other people’s consideration. One such practice is the use of Hungarian notation in programming.

Simply put, Hungarian notation, or any similar kind of application notation, suggests that variable and function identifiers (i.e., names) reflect the kinds of data they store or return, or generally how they’ll be used. So, for example, a variable used as a flag might be a Boolean named bHasOne or an array of names would be stored in aNames (these are greatly simplified notation syntax; you can see more examples in the Wikipedia article). One primary benefit of using such a system is having a consistent naming scheme, which is always absolutely critical. Programming notation can also make your code easier to read, as the identifiers themselves become de facto comments. That being said, that same Wikipedia article, and several other places online, have big name people suggesting that Hungarian notation is redundant and unnecessarily tedious. While it may be useful for untyped languages, like PHP (where you can easily, inadvertently change a variable’s type), strongly typed languages and OOP specifically have no use for notation. Again, I don’t personally adhere to these conventions but thought it’d be worth mentioning for those unfamiliar with the concept.

(And, as an aside, if you’re looking for an interesting read, here’s a good, long article on all sorts of coding issues.)

The performance of any Web application is greatly impacted by how well the database application is being used (if being used, of course). The four biggest impacts on performance are:

• The storage engine(s) used
• How columns are defined
• The existence of proper indexes
• How queries are written and executed

MySQL supports many different storage engines, each with its own strengths and weaknesses. Which you choose isn’t just a performance issue, it’s also one of features, like whether you need to support FULLTEXT searches (and therefore MyISAM tables) or transactions (which means InnoDB). Sometimes you can get away with using HEAP tables, which exist only in memory. There’s no permanent storage with HEAP tables, but the performance can’t be beat.

For the column definitions, the first goal is to use the smallest possible size for each column. This will be a limitation in your application, so the column’s size still needs to meet or exceed the largest possible value to be stored, but, generally speaking, the more data you want to possibly store, the more space will be required for all the data stored. You should also avoid allowing NULL values in columns. This is a factor in both good database design and in performance optimization.

The indexes you establish, and how they are used by queries, is a serious subject that requires a book in itself. To start, make sure you read MySQL’s own guide to how MySQL uses indexes. Second, learn to run your queries using EXPLAIN to see what, exactly, MySQL is doing when it executes that query. Also, of course, only select the data your application will actually need. No need to retrieve information that won’t be used. And always go back and double-check that your queries need all the clauses and references they’ve got. I’ve been known to leave legacy conditionals in queries that have no effect whatsoever.

For more on some of these topics, see the MySQL manual, of course (which has a section on optimization), the PlanetMySQL blog, and this article at DatabaseJournal.com. Also, if it applies to you, you can tweak MySQL’s behavior from a hardware/OS perspective. For an introduction to this subject, with respect to Linux, check out this article by Jeremy Zawodny, an expert on MySQL performance tuning.

I’ve been writing a lot about the Yii framework for Web development using PHP. I’m a big fan of it and expect I’ll be using it for some time to come. I recently came across DooPHP, which I think is also worth consideration (although I haven’t yet used it myself). Besides having a really sharp Web site, some of the strengths of DooPHP seem to be:

• GUI tools for auto-generating code
• Many types of caches for improved performance
• support for replicated databases (great for demanding sites)
• REST support

I don’t plan on changing frameworks for a while, as I’m quite pleased with Yii, but if you’re looking for a new PHP framework, you may want to consider DooPHP as well.