Back to articles list
- 3 minutes read

My Weirdest Database Experience

Back in the day when I was still a PhD student, I helped to organize two scientific conferences that took place in my institute. If you’ve ever been to a big 1000-person developers’ conference, scientific conferences are nothing like them. They usually have around 100 participants; a 300-person conference is considered big. Scientific conferences are organized by the faculty of the university where the event takes place, with some help from interested students or PhD students.

My task was to prepare a registration system for the users. It was a very simple PHP + MySQL application. The participants could choose from a couple of registration options (Student, Full Registration, Speaker Registration, etc.). They could make a payment, and after the payment was processed, they could download their invoice. Nothing particularly fancy, nothing too difficult.

We had a little problem with the administration interface, which we needed to list registered users and the registration option they chose, and if they had already paid. Occasionally, someone paid with a bank transfer and the payment had to be handled manually. Almost all people involved in the organization were Computer Science majors. They knew how to connect to the database, list all users, or update user data. However, we had part-time help from an administration lady who was not a computer science major and most of the registration tasks were to be done by her.

Does it make sense to create a full user interface which only ONE person will use? Building an administration interface would take a week: design the interface, implement it, test it, then redesign it a little. You know how these web things always turn out. The solution we came up with was to find a lightweight MySQL web interface (I think we chose MyWebSQL) and set it up. Then we created an updateable view which collected all of the user information that our administration lady needed. Add a daily backup system and that’s about it. We instructed the lady on how to use the view (“Do not click on other tables, just on this all_users_view”). We gave her the URL to the interface, the user name and the password. She could even work from home if she wanted.

I remember that at the time I was slightly shocked by the solution. What? No interface? What about security? “Always validate user input,” and all of the other rules they taught me in Software Engineering class. Some five years later, I think the simplicity of this solution was brilliant. Why waste a whole week of work instead of doing something that took just a couple of hours to set up? Validate user input? Our administration lady wasn’t a programmer, but that didn’t mean she was stupid. We told her how to use this system and what she shouldn’t do, and she did just fine.

Conclusions? Just because you can do something (program the user interface) doesn’t mean you have to do it. Try to think out of the box. You can build a usable piece of software without writing a single line of code, just re-using the blocks that are already out there (in my case: a web interface for MySQL, the MySQL database, and some knowledge on how to create an updateable view). It was a one-time solution, but it was simple to set up, simple to use and it worked.

What are your non-standard database experiences and what did they teach you?

go to top