Don't gloss over the database!

I think I'm getting old. I've been thinking about what to write for these articles, and instead of focusing on the database, on the hard stuff, I find myself thinking about the Java youngsters and what I can teach them. I'll be the old man teaching young ones how the classic database is worth their interest. Quiet please, the Guru is speaking now ;).

There is something common among some Java developers, especially the hardcore ones. Those who've pledged themselves to the Java flag. I call it:

NJD - "Not-Java Disorder" - the unwillingness to use something that is not implemented in Java.

 

"Unwilling" is kind of a euphemism. Some of these people really panic if you take away their Eclipse support. They deal with non-Java solutions in one of three ways:

  • by discarding - "we're Java programmers and it's not Java, trash it"
  • by layering - "we're gonna code lots of layers to hide this obscure not-Java"
  • by rewriting - "we have to rewrite it as Java code"

 

And what do they think about the humble database, you ask? I think RDBMSs are perhaps the most unliked and misunderstood part of system architecture.

Most production-ready databases are writen in C or C++. From the Java perspective, C and C++ are ancient. Processor-dependent binaries, shared libraries, and memory management by hand (segfaults) are hard to understand for the Java guys.

Java relies on a virtual machine which hides some platform-related differences. Sometimes, I think, it hides too much. Java was developed as a tool for the average programmer, so there is a tradeoff between comfort and performance. The designers of Java decided to make it easy to develop. Performance comes later as part of the virtual machine (JIT, and GC tuning), and is hidden from the programmer. Java is like a city car, affordable and easy to ride. Like a modern car, it has all the systems designed to help you drive with little effort.

Databases, on other hand, are from the performance era. They're like racing cars; everything is about performance and endurance. Database designers use all their available resources to reach this goal. Databases are hardwired to the OS layer, and sometimes to the hardware. If a particular OS or piece of hardware has something that makes the database run faster or safer, it will be used. Named pipes, shared memory, queues, semaphores, raw access to block devices, bonded netword devices, processes, and so on. Java guys say "Yuck!" but DB guys say "Yummy!" Databases are down-to-earth, while Java sometimes looks like room full of cushions, I mean objects :).

Everything that Java developers hate in databases comes from a misunderstanding. They don't get that databases are built on totally different assumptions, ones that prize performance over ease of programming. They hate a complex type system, where types have explicit limits; varchar(255) for example. They hate stiffness of schema. They hate the non-imperative nature of SQL. They hate that they have to learn about OS features. They hate filesystem sync operations. In other words, they hate everything that is not a Java object :D.

Most of the things they hate in the database are performance tradeoffs. Like it or not, life is full of tradeoffs. So if you don't accept the limited nature of dabatabases, you'll probably try to apply a one of the "Not-Java" solutions described above. I wish you luck. Probably you'll fail, just like most of us :). The only solution I've found is: accept it, use it, profit.

Are you working with real bits, or still dreaming in objects?