If you enjoy this type of thing (who doesn't?) and you're into databases and especially Oracle, there's a site inspired by The Daily WTF just for Oracle blunders! Check it out: Oracle WTF!

I found out about this via Tom Kyte's post, so I might as well also share some of his awesomeness:

As an aside, anyone that knows me, knows my mantra - written many times:

• You should do it in a single SQL statement if at all possible.
• If you cannot do it in a single SQL Statement, then do it in PL/SQL (as little PL/SQL as possible!).
• If you cannot do it in PL/SQL, try a Java Stored Procedure. The number of times this is necessary is extremely rare today with Oracle9i and above.
• If you cannot do it in Java, do it in a C external procedure. This is most frequently the approach when raw speed, or the use of a 3rd party API written in C is needed.
• If you cannot do it in a C external routine, you might want to seriously think about why it is you need to do it...

Ok, back to writing good code, not crappy at all! :)

For example, check out the documentation for the NTILE Function. Yeah, sounds kind of boring. What good could it be in the wonderful world of web development? After all, who manages employee or sales tables anymore...

Answer: generating tag clouds.

Here's how you do it (elegantly) using the NTILE function instead:

SELECT name tag_name,
            num_results_per_tag,
            ntile($numFontSizesInCloud) over (ORDER BY num_results_per_tag) as font_size
  FROM (SELECT name,
               num_results_per_tag
          FROM tag
         ORDER BY num_results_per_tag DESC)
 WHERE rownum <= :num_tags
 ORDER BY name;

What this query does is take all tags and number of items tagged with that tag and orders them by that number (so most popular tags first). You can specify how many tags to retrieve for the clouds via the :num_tags parameter. (Note: instead of using this clause to limit number of tags by their row number, you can use a subquery to retrieve a specific set of tags, e.g. user-specific tags, page-specific tags, etc.)

After you know how many tags to retrieve, you use the NTILE function to put all the tags into "buckets", or font sizes (or classes) your tag cloud will use. How many buckets you have depends purely on your whim and you can specify it when constructing the query using $numFontSizesInCloud (or some other cleverly named variable). (Note that this value is not bound as it is not a parameter for the SELECT statement.)

The NTILE function creates however many buckets you want, then it evaluates the data in the OVER clause to assign the bucket to each of the tags returned. In your template then, you can simply display a tag cloud like this:

It's then up to your CSS to define font sizes or whatever class names you want to give them (don't quote me on my CSS usage...) and you're done!

While PHP can do a lot of great things by itself, it can do much more when you add a relational database. Whether you use MySQL, PostgreSQL, Oracle, MicroSoft SQL Server or SQLite, the way you design your schema and build your tables has a big impact on the abilities of your application. By the same token, mistakes in your database structure can be very difficult to fix or overcome. A little bit of careful planning can go a long way.

It's a pretty good article about database design and I think all PHP developers who are just starting to integrate databases in their applications should read it. However, there are a few things I'd like to add and point out.

Here's a quick primer:

SQL - Structured Query Language. This includes all your SELECT queries.

DML - Data Modification Language. This includes any statements that change data in your RDBMS. All your INSERT, UPDATE, DELETE, MERGE go here.

DDL - Data Definition Language. How you define objects in your RDBMS. A database object is a table, index, sequence, etc. Your CREATE TABLE, DROP INDEX, etc. fall under this category.

It makes me cringe when people say "SQL statements to create your tables." I understand that SQL has kind of become to mean "all database code", but it really isn't. There's a huge difference between the three categories I listed above and it really helps developers organize how they think about database development if they understand the differences between the three.

For example, did you know that you can't create a table with auto-increment starting at a value which is the next auto-increment value from another table? Why is that? The answer is simple: you can't mix DDL (create table) with SQL (selecting a new value). If you understand that DDL and SQL are different, the answer is obvious. If you don't get the distinction between the three, the answer can be kind of magical and confusing.

constraints vs. indexes vs. keys

You can think of a constraint as a "check" that your RDBMS performs when you execute a DML statement.

An index is a physical object in the database (created with DDL).

A key is more of a conceptual construct which combines the characteristics of a constraint and an index. It is a constraint in a way that it makes you RDBMS enforce a rule when DML is executed (e.g. ids of users must be unique and sequential). It is an index in a way that it is stored separately in the database and can be used for querying (via SQL). You create it via DDL, of course.

I think the article's explanation about keys, primary keys and foreign keys was aimed at newer database developers, and especially ones using MySQL. Good database design stems from understanding the relationships between database objects and constraints and indexes help enforce those relationships. Since you, the developer is who puts these constraints and indexes in place, it is in your benefit to learn how they work.

Designing for performance

I applaud the article for pointing out that good design takes precedence over optimization and that good design provides good potential for good optimization practices. I also really liked him pointing out that it's important to know what you should optimize. Figuring out what your bottleneck is will go a long way toward figuring out what next steps you should take.

Speaking of optimization...

Mac's article is definitely very MySQL-oriented. I would really love for everyone to enjoy reading Oracle documentation as much as I do. But if you don't, at least read this awesome part about Oracle's EXPLAIN PLAN which beats MySQL's by a long shot. I think the article does not focus much on the explain plan because MySQL's support for it is very limited. Oracle gives you so much information in an explain plan that it is really no excuse to not know what your queries are doing.

Let the database handle data

The article points out that it's sometimes difficult to know what code to store in the database and what in PHP. Personally, I'd love to keep it all in the database (just so you know my bias), but even if my views were more liberal in this respect, I'd disagree with the article that the choice may sometimes be unclear (and definitely in the examples the article provides).

The word "database" contains the string "data" - that should be a pretty good clue what the database is for. (Ok, that's my snarkiness for this post.) A database is really REALLY good at handling data. Enforcing auto-increments or managing referential integrity (e.g. foreign keys) via PHP would not only be cumbersome and error-prone, but it also violates the principle of using the best tool for the job.

Overall, it was a pretty good article, albeit with a MySQL slant. I'm glad that the PHP community recognizes that most PHP applications will at some point use a database and that solid database development skills in PHP developers are important. Learning how to write database code well can also give you a whole new set of solutions to a lot of challenges you encounter in your application.

<3 databases!

Work is starting on 2/4 (Monday) and tomorrow I'm doing a mini presentation on how this tool will work. Here are some excerpts:

What is it?

A tool to keep database objects and stored procedures synchronized with application code in a multi-developer environment with a short release cycle and multiple development branches. Tie-in to svn (subversion) for version control.

Why do I need it?

Historically, applying database changes falls onto the shoulders of both system administrators, database administrators and developers. This role is not very well defined and varies widely from project to project. DbMorph allows the roles to be more defined, as follows:

• Developers write the database changes: any DDL changes, DML and updates to stored procedures.


• DbMorph generates a file that can be run on an existing database schema to update it (or downgrade it) to a desired version. DbMorph guarantees that correct versions of stored procedures are applied and that no change is applied out of order or more than necessary


• Admins or developers can now run the generated file on a desired schema. This is most useful in two main scenarios: administrators (sysadmins, dbas) can apply these changes to systems in production during releases and developers can apply these changes to schemas they manage on their own (e.g. in a local dev setup) during development.

How will it be released?

DbMorph will be released under the new BSD License. This means that the name of the author is preserved as the software is used, however, the end user has the freedom to do anything with the software (as long as they preserve the author's name).

I did not choose the GPL license due to its viral nature - it infects any code it is a part of and any code that uses it would have to be then further released. This would not work in a setting such as an agency where you might write software for someone else who wants to own it.

How do you know it will work?

I have already written what could be considered a very technology-specific version of this tool and use it on a daily basis. It works for the specific project I'm using it for, but it does not support a variety of databases nor applications in various programming languages.

Wait, doesn't a tool like this already exist?

There are a few tools that attempt to support similar functionality, but in most cases they miss the idea that stored procedures (e.g. code written in PL/SQL) and application code (e.g. PHP, Java) are both maintained under version control. The feature that differentiates dbMorph from other tools is considering any stored procedures as living and breathing code under svn. It will retrieve the correct versions of those files depending on the database revision within the development process. This especially applies in environments with multiple development branches that release code on a frequent basis.

Ok, gimme the specs!

This tool will be written in Python. Doing so makes the tool OS-blind and portable.

The tool will give users freedom in how database deltas (changes) are stored. The default storage engine will be XML. Adding a new storage engine will simply mean implementing a provided interface.

The tool will attempt to support a variety of databases. The original release will include support for Oracle and MySQL.

The tool depends on svn (subversion) for version control. Svn is a widely-recognized version control that will most likely be around for quite some time (*cross fingers*).

DbMorph can be run from command line.

I've never managed an open source project before, so this will be an interesting experience (any thoughts, ideas, words of warning are welcome). Work is scheduled to start Feb. 4th, 2008 as my company's graciously allowing me to use up to 50% of my time for an R&D project. Yay!

It looks good, although I'm worried it's missing support for stored procedures, which will be especially important when working with Oracle.

In May, I'm talking at php|tek about how to keep your PHP and database in sync. This talk mainly focuses on a database schema manager that Rob Allen describes; I have already written this tool for a project I'm currently working on, mainly driven by the need to share database changes across many developers.

NEWS! This year I'm releasing this tool under an open source license. I am not going to tie it into any framework - I think this tool can be useful on any project and doesn't need to be written in the language of the application.

Now with Rob's proposal there's more pressure to get this out the door - I will have a sourceforge link for all of you soon.

P.S. It'll be released under the new BSD license - thanks to everyone in #phpc for helping me understand the downfalls of certain licenses!

Along with great PHP tips, the calendar also features many of the prominent PHP personalities (and their photos!). The PHP community is one of the nicest communities that grows around a programming language and/or philosophy that I have ever encountered. Go on to the calendar to find out about its people. And thanks again to Chris for compiling it!

Keeping Your Database and PHP in Sync

As your application changes, so will the database that supports it. Keeping database objects and stored procedures synchronized with PHP can be a challenge in a multi-developer environment with a short release cycle and multiple development branches. This talk describes a method for containing database changes in a way that the application understands–think Ruby on Rails “migrations”. Changes to the database are applied when appropriate PHP changes have been made. The method is database-blind and allows the developer to choose a storage engine, such as XML. Bring your favorite svn tricks to share!

Angering Database Gods

Rapid development techniques often promote abstraction of database interaction. Many available frameworks offer mechanisms that can prevent the developer from making database design decisions. This talk focuses on describing specific approaches to utilizing a database in your application and the pros and cons of each choice. We will talk about proper database design, using PHP to construct SQL, limiting access to the database via caching an d others. As the talk progresses, we will attempt to design a scalable and high-performance database-driven environment for a social networking site.

My husband says that I am now fluent in Blurb. See you all in Chicago!

Recently, Chris Jones sent me a photo he took during ZendCon this year. I did a presentation via iChat for the Zend Unconference. Sorry for the delay in posting it - here's what the presentation looked like:

Matthew Turland on the left, me inside the computer. The future is now! Thanks for the photo, Chris!

On a current project (Oracle + PHP), I wrote (with a few coworkers) a database management tool that does what Ruby on Rails does in terms of migrations, with one huge difference: keeping track of database packages and which version of them should be compiled given the specified DDL and DML change. It works really nice - it still has kinks to be worked out and some edge cases to address, but it's a really useful piece of code that has greatly reduced the amount of whining among developers who have to make frequent database changes. I submitted a talk about how it works for php|tek 2008, so maybe you can hear me talk about in detail at some point.

Now, PEAR has a proposal for a DbDeploy. This is a great idea! Unfortunately, it looks like the proposal and the code written for this package completely fails to address the fact that a database change (or delta) may include changes other than simple DDL and DML statements. Most of the code I write for my applications includes tons of stored procedures and chances are, dear reader, that you are in the same situation. So it looks like I'm getting myself involved in writing this package - stay tuned!

Setup consists of two parts:

1. Installing Oracle Instant Client on Linux
2. Getting and compiling oci8 extension for PHP

It's very simple or "easy", so try it out!

You may remember me complaining about the shortcomings of Ruby on Rails migrations system. One of the talks I submitted is about a script I wrote with some coworkers that works like the migration system but it also considers referential integrity and changes to stored procedures. It will keep you PHP and database in sync at all times - I hope I made the description interesting enough for the organizers to pick it!

Hosts/Guests:

1. Paul Reinheimer
2. Sean Coates
3. Sara Golemon (aka DYG)
4. Ben Ramsey
5. Maggie Nelson <-- yours truly
6. Chris Shiflett
7. Terry Chay
8. Dustin Whittle
9. Ed Finkler
10. Derick Rethans

Happy listening!

But, more importantly, this XKCD comic is making rounds on all database-related blogs. Tom Kyte, Pete Finnigan, and many others are referencing it like it's going out of style. At least 6 people IMed me this morning telling me about it. If this comic teaches at least one person about SQL injections, we win. Thank you, XKCD! (*appends name to list of possible baby names*)

In other happy news, Chris Jones reports that the OCI8 extension for PHP has just been released with changes to support Oracle Database 11g "Database Resident Connection Pooling" (DRCP). Yay!

Fortunately, though, thanks to the organizing powers of the bearded Patrick Reilly, I will be able to participate a little bit by giving a talk at the PHP Unconference '07 at ZendCon. I'll be presenting on Tuesday, October 9th at 5pm PST via iChat. (Technology = science + awesome!) If you tune in, you'll see a polished and improved version of my "You Don't Need a DBA" presentation, which I gave at php|works earlier this year.