Phill Haack is talking about integration from the database point of view. I had the pleasure of dealing with several projects that involved interfacing to legacy systems. Invariably, the suggested solution was to use the legacy system database directly, and build the application from that.

It was assumed that this would be a less costly endevour than building interfaces at both ends and hooking them together. A few stored procedures and many (many) views later, we had the integration completed on the side of the legacy system. Then it was time to really interface with those systems, at which point we discovered just how bad that was going to be.

I will leave aside the schema warts that we run into, let us talk about how complex it was to use it in practice. Versioning support simply doesn't exists, you are vulnerable to anything that run on that system (a long report is running, say goodbye to the app for the next half hour)...

But by far the biggest issue is the limited ability to express an interface that has a business meaning. ODBC it very suited to express data, but data is not business meaning. Paul Stovell wrote about SP being an interfaces, and yes, they are. But I have very little intrest in an interface like "GetCustomers" that gives me the select from Customers table.

Paul also suggests that exposing those stored procedures as web services will eanble a more flexible approach, where the DBA can change the intrenals without affecting my code. In my expriance, that doesn't work, while WS may be able to solve the issue of versioning, it require a lot more work than is often applied to it. What you end up with is the result set serialized as XML at best, and huge deployment issues for the simplest change.

My opinion is that it is important not to try to abstract the database. It has significant capabilities that nearly all abstractions simply ignore. I want to get all the employees joined to their salaries on the last three months. If I am working against the database, it is easy, I just do it. If I am working against a Stored Procedures layer, or worse, Stored Procedures+Web Services, then we talk about new stored procedure, that now needs to be maintained, checked for duplicated code, deployed, etc. If we are talking about WS as well, we need to publish a web service, write a schema, etc. Now I need to talk to the new Web Service, and changing the stored procedure now means that I have to change (at a minimum) three places, the stored procedure itself, the web service, and the client code.

Paul seems to believe that talking directly to the database implies that there is no contract involved (and I fully agree that a contract is important). I think that the mapping inherit in working with OR/M technologies is the contract. I can safely modify my database and my queries without affecting the code, and I retain all the stregnths of the  database.

*I am talking about views and SP, not the ODBC API itself, of course.