Repeat after me: MySQL is not a filesystem

I came across this gem on DZone this morning. It’s a tutorial on storing images in a MySQL database (using PHP). There are several things in the tutorial that I don’t agree with, but I’ll let those slide. What really bugs me, is how it fails to mention that this is a very bad idea.

A relational database is not a filesystem. Files go on a filesystem. Relational data goes in an RDBMS. Repeat that a couple of times.

The most compelling argument for this, is performance. I did a quick test. I did a google image search on stupidity and downloaded the first 10 images. I then wrote PHP scripts to serve them up in two ways:

1. From a MySQL (MyISAM) table with 2 columns: ID (int, auto_increment) and DATA (mediumblob)
2. Using readfile.

The third test method, “FS”, simply loads the image over HTTP directly, without any intermediary scripts.

The results are the average of running Apache Benchmark 10 times: 10 concurrent requests, 1000 requests per run.


As you can see, the MySQL approach is a hell of a lot slower than the more sensible FS approach.

The best way to store your images (or other binary files) is on the filesystem. Every modern web server does a good (or excellent) job of serving up static content. Storing them in a database is by far the worst possible solution. Not only because it’s slow, but also because it complicates database backups: MySQL dumps with binary data don’t compress very well, causing the whole database backup to be slower and larger than needs be.

So please, be sensible. Store your files on a filesystem.

Symfony2 and Jenkins

I was a bit surprised to see that Symfony2 doesn’t come with an ant build file for Jenkins by default, so I spent a bit of time whipping one up for you (well, for me, really):you can get it here.

Maybe it’ll work for you, maybe it won’t. The project I’m working on has the complete SF2 distribution in version control and all of our bundles in the src folder. It’s easier to test & ship the code this way. If you want to test a specific bundle or don’t want to have SF2 in version control, then you’re on your own :-).

Git pre-commit hooks

Git’s pre-commit hooks are pretty useful. You could use them, for instance, to run your tests and abort the commit if there are failures. All you have to do is write a simple shellscript. The example below runs a php syntax check on all php files and aborts the commit if it detects anything invalid. It’s based on a script that was going around at $work, no idea who the original author is, but kudos!

Save this as .git/pre-commit, and make sure you make it executable (chmod u+x)!


error_msg=$(mktemp /tmp/error_msg.XXXXXX)

if git rev-parse --verify HEAD >/dev/null 2>&1
        # Initial commit: diff against an empty tree object

# Get a list of modified php files and run php -l against them.
for indexfile in `git diff-index --diff-filter=AM --name-only --cached $against | egrep '\.(php)'`
    # Don't check empty files
    if [ `git cat-file -s :0:$indexfile` -gt 0 ]
        case $indexfile in
            *.php )
                # Check php syntax
                git cat-file blob :0:$indexfile | php -l > $error_msg ;;
        if [ "$?" -ne 0 ]
            echo -n "$indexfile: "
            cat $error_msg
            syntax_errors=`expr $syntax_errors + 1`

rm -f $error_msg

if [ "$syntax_errors" -ne 0 ]
    echo "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
    echo "@@   Error: syntax errors found, aborting commit.   @@"
    echo "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"
    exit 1

Extending or modifying this script to suit your needs is pretty trivial. You can expand the egrep and case to include any other filetype you want to perform magic on, or you can run your unit tests after the loop, or send an e-mail, or make coffee, etc.

On Ruby & PHP

So I quit my job. That was a relatively big change for me, after spending 3 years sat on the same chair working with the same team. But I felt it was time for a change. The new job is quite a bit different from the old one. One rather obvious difference is the programming language .. I’ve gone back to my proverbial roots and am now churning out PHP on a daily basis. And because I’m such a programming nut, I’m working on some after-hours Ruby projects as well.

PHP and Ruby are both obviously very different from Java – and very different from each other. Sometimes in good ways, sometimes in bad ways. Syntax wise, PHP and Java are very similar. The dollar sign on my keyboard is definitely seeing a lot more action now, but other than that not many dramatic finger changes are required. PHP doesn’t have have a bunch of things I like, like final method arguments, multit-hreading or a half decent collection of standard classes. What it does have is excellent documentation and easy & interesting meta-programming. That, and it’s obviously much more tailored for the web than Java. For the first time in 3 years I *don’t* actually need a whole armada of frameworks just to get something simple done. Still .. I miss my (Concurrent)HashMap, ArrayList, and most importantly my trusted BigDecimal.

And then there’s Ruby .. Even after a couple of months of Ruby, I have very mixed feelings about it. The documentation sucks. Don’t argue with me, it really does suck big fucking donkey balls. RDoc (especially online) is to JavaDoc what Spam is to nice and tasty Prosciutto. Then there’s the lack of backwards compatibility (granted, Java may take this a bit too far, but still).

And then … there’s the syntax. This is where my feelings are mixed, rather than plain negative. There’s too much choice. You can mix and match a bunch of styles, do..end, curly brackets, semicolons or no semicolons, method arguments with or without braces, and the list probably goes on. This leads to code that’s hard to read (and thus hard to maintain), especially when different people stick to different styles. On the other hand, it also leads to nice syntactic sugar. Clever use of methods can make it look like you’re defining your own keywords, which is very nice for creating your own DSLs. It’s also rather nice to have Operator Overloading, and being able to treat everything like an object also has its benefits.

Still .. my feelings remain mixed. And in spite of everything, I feel like Java is still the only choice for Serious work. Not only because of the amazing documentation, the excellent standard library or even the massive community, but also for the amazing JVM, its security model and its thriving ecosystem.

Java ain’t dead, folks.