I can picture a scene in the early nineties...
Programmer: "Look at this cool app, it is written 'Object Oriented'"
Manager: "I see. But it doesn't seem to do much"
Programmer: "Yes, but... it has objects, polymorphism, encapsulation and other great things!"
Manager: "Hmmm, interesting. Is it connected to the database?"
[Long pause]
Programmer: "Bugger!"
And so the Objects vs Databases war was born. It is a battle that has been raging for as long as object orientation as been around. A battle that has been fought in newsgroups, essays, offices, conferences, blogs and podcasts. Every few years something comes along that raises the battle to the fore, introducing it to a fresh, new generation of techies that take it on with renewed vigour and youthful passion.
One would think that the gap between objects and databases would be so narrow as to be insignificant - and technically that is probably the case. The first generation of OO development tools couldn't even ping a database, never mind do anything with the data, but that was solved over time with better and easier API's. ODBC, BDE, ADO, JDBC, ADO.NET and a myriad of connectivity technologies made it trivial to 'talk to' the database - a programmer puts in a couple of parameters and the drivers, developed by the database vendors themselves, seamlessly translate the API calls into something that the database can deal with and understand. Databases, using frameworks such as ADO.NET, have become more object friendly - allowing database communication to be done with objects. OO languages and their frameworks have in turn become more database friendly by providing support for set based operations, keeping data diffgrams, allowing databases to determine object identities and so on - soiling their object purity for practical reasons.
Unfortunately the gap, the Object-Relational Impedance Mismatch, will never be fully closed. There are enough key philosophical differences between the two models to make it impossible (Although, to the average developer, these differences may not be particularly visible or relevant). It is the idea that there are big differences between the two models that sets that object people against the database people and visa versa. It is funny to watch the war continuing to be raged by fresh recruits long after we have realised that it is a pointless battle. One of the recent (two years ago) definitive essays on the topic is Ted Neward's 'The Vietnam of Computer Science' which, although it is a bit of a long read, offers a good analogous view as to why the gap will never be closed.
What bothers me, is not the fact that the gap won't be closed, but that people are not willing to accept that the two technologies (OO applications and SQL Databases) are complementary rather than competing. We see it all the time, OO developers complain that it is difficult to get data into the database (which it isn't really - you should have tried it twenty years ago) or that databases don't work well with the current TDD fashion, or any other thing that they can make up to point fingers at the database. Database people complain that OO developers don't know enough about the database to write SQL or that they are not considerate of performance or security, or anything else that they can use to point fingers back at the developers for poor database performance or implementations. Rather than trying to see one another as parts of the overall enterprise IT, they alienate each other and draw back into their own camps. The adversaries, the people, in this war are moving away from each other even though the technologies are moving closer.
The brutal fact of the war is that the OO people are winning, but not necessarily for technical reasons. The OO camp makes the most noise on the Internet and seem a lot more cool. They are finally developing processes that make OO development easier (arguably a problem database people solved a long time ago) by making TDD fashionable and cool. The problem is, as they will tell you amongst other gripes, that the database does not support TDD as the database cannot be 'mocked'. "Bad database!" everybody shouts while pointing fingers at the poor culprit. All the younger developers are crowding around the cool programmers, the OO-TDD-IOC-Mocking programmers, giving the database a cold shoulder.
Ask a junior developer if it is okay to use datasets (in .net) and he or she will tell you, with the utmost conviction that you should never, never use datasets. A more seasoned developer will tell you a different story, they will tell you that in some cases, in some environments it is okay to use datasets (although they never would). They have even come up with a term to refer to these scenarios, and they call it CRUD, which stands for Create Read Update Delete - referring to basic operations on fairly flat data. Not something cool like VADER (View Add Edit Delete Restore), but boring old crud - and there's the coup in the minds of the market. CRUD is demeaning. Crud, as defined by a dictionary is 'A coating or an incrustation of filth or refuse' or 'Something loathsome, despicable, or worthless' - and the OO people have managed to get everyone to refer to databases using the exact same word! In the minds of everyone the database has been reduced to something disgusting that needs to be scraped off the bottom of your shoe before you step in the house.
The more the Object people win the war and alienate the database people the worse it will be for themselves in the long run. The pure object model simply does not scale - there will always be something that persists their objects somehow and there will always be some mismatch. For now it may be SQL based relational databases and in future it may be columnar databases or something else in 'the cloud'. Simply, the amount of data being generated and consumed needs to be stored, indexed, backed up and distributed - and the technology that does this, from Microsoft, to Google, to Oracle will be specialised technology that will be at odds with a pure object model.
Also, database people need to get out of their big gleaming data centres every once in a while and understand the data needs of modern business. The desire for agile software development practices, loosely coupled architectures, messaging and other current techniques and technologies is driven by business demand. The days of a large, centralised monolithic database that nobody can touch and change have been superceded by the need to rapidly deliver business functionality in a highly competitive market.
Object people and database people are actually on the same side and it is time they started behaving that way. It is time that they learned more about one anothers' domain so that they can figure out how best to leverage all the technologies available. It is time for technical people to realise that there is a future and a career when working closely with the database.
I will play my part and will spend some time focusing on the glue that binds these two worlds, the heart of the impedance mismatch - I am going to spend some time talking to people about data access. It sounds like being in no mans land, with a high likelihood of being lynched, or ignored, by both sides. But for me at least, it is time to start bridging that gap - how about you?
Simon Munro