Once upon a time I wrote a computer program that did not require data. It was called helloworld.exe and it was awesome. It was also a wee bit useless. The essence of useful software is taking input, doing something with it, and spitting something out.
There is lots of data out there. My first professional gig after university was consuming text files dumped out by a COBOL app. (They were delicious.) You can parse XML, munge HTML, manipulate images, or decipher networking protocols. But despite the variety of possible data sources, we end up sticking a lot of our data in relational database systems.
And then we write a lot of code for moving data in and out of the database. And then we complain about how much data access code we have to write and maintain. In Survival Skills for Developers, the first item for your basic survival pack is a data access toolkit (homegrown or open source or commercial). The reason is not to be trendy or to sound up-to-date at developer conferences. The point is to make better use of your time by relying on frameworks and libraries to do some of the heavy lifting for you.
Do Not Be Afraid
In the .NET programming world, ADO.NET is the underlying data access technology. Many data access patterns and frameworks have been built on top of ADO.NET and yet scores of developers still write ADO.NET data access code the way they learned nearly a decade ago. What a waste.
There is no reason to be afraid of modern data access techniques. You do not have to rewrite your existing codebase. .NET programmers can still use classic ADO.NET when it’s expedient. You can mix and match tools and frameworks. I have a small project that I’m transitioning from SubSonic (used during prototyping) to NHibernate. Currently the code features a mix of SubSonic and NHibernate as I transition and it works just fine.
Frankly I think developers who refuse to explore alternatives are being irresponsible. I’m not holding up any specific frameworks, toolkits, or approaches as best. I’m simply saying that a failure to be well informed about options is intellectual laziness and we cheat our employers, clients, and stakeholders when we insist on writing everything by hand every time we need a record from the database. We would question the judgment of a house builder relying on all manual tools, yet we mindlessly churn out the same data access code over and over and over again.
Stop Freaking Out About Inconsequential Performance
A mental roadblock for many folks is a worry about performance going down the toilet by relying on something like an ORM (object-relational mapping) tool. If there is one serious mental shortcoming amongst programmers, it is our obsessive need to prematurely optimize everything even when there are ample computing resources to deal with our less-than-completely-efficient code.
Stop freaking out.
The JVM and the .NET runtime have proven that letting the computer handle some tedious work is totally worth it even if it’s less efficient than what you could (theoretically) write by hand.
CPU time is cheap. Programmer time ain’t. Spend time optimizing code only when it becomes necessary.
Do You Really Need a Database?
Simple lists of objects can be similar to tables of records. The relationships between objects can be similar to the relationships between tables. Nevertheless, there is a mismatch between object oriented programming and relational data (perhaps you’ve heard of the object-relational impedance mismatch). Depending on your situation, you might not really need a relational database. Check out some of the technologies in the NoSQL side of the world for alternatives to relational database storage engines.
What’s Available?
There are a lot of options out there for working with relational data. Check out Barry Gervin’s article All I Wanted was My Data for some options.
What are your suggestions? Drop them in the comment box.