Anne Truitt Zelenka

Effective software development requires attention to design tradeoffs. You can’t get everything you want all at once. For example, sometimes it’s better to use flat files for data storage instead of a DBMS. Yes, databases give you all sorts of nice features: structured data, transaction control, easy querying and analysis, better protection against data corruption. But you have to weigh that against the performance cost that databases impose.

We’re going to have web-based chat at the Office 2.0 Podcast Jam. In preparation for that, Amy and I have been evaluating free chat packages that we can install onto our web host. Part of the Office 2.0 gestalt is browser-only software with rich interfaces. How do you get that? Ajax, of course. But Ajax alone won’t provide a really responsive chat. You have to consider the backend processing too.

We tried out AjaxChat and phpMyChat first, but I wasn’t pleased with their performance. To keep a good rhythm, a chat capability needs to update immediately. I type fast, and when I hit “Enter,” I want my words to appear immediately. I also want to see other people’s words immediately. This helps avoid the disjointed conversations that you sometimes see with IM and chat. It keeps people involved. Ajax helps somewhat with this, but it can’t overcome sluggishness on the back end. Both of these packages store message data in a database. That means every message you type in needs to first get written to the database before it gets displayed. That’s bad news. That’s a bad design decision. It might be okay to hit the database to grab a blog post. But it’s not okay to hit a database for one line of conversation.

I found a web-based chat that uses flat files: phpFreeChat. It’s incredibly responsive. If my data gets corrupted or lost, so what? Chat history is relatively transient data. Making it quick is far more important than keeping it structured, accessible, and protected for long periods of time. Just because nowadays everyone has access to MySQL on their web hosts doesn’t mean your software should use it. Before you mindlessly choose a DBMS for data storage, think about whether the file system or RAM would better meet your most important requirements.