Domain Logic And Sql Article

Comments based on the Domain Logic and SQL article by MartinFowler:

http://www.martinfowler.com/articles/dblogic.html

: Often application developers aren't allowed to define views and database developers form a bottleneck that discourages application developers from getting views like this done. DBAs may even refuse to build views that are only needed by a single application.

This is a vendor (or tradition) limitation. Some RDBMS allow "temporary" or user-specific views. As far as DBA problems, see DbasGoneBad.

: Using views, or indeed stored procedures, provides encapsulation only up to a point. In many enterprise applications, data comes from multiple sources, not just multiple relational databases

This is mostly a vendor limitation. I see no reason why a view could not execute code in a programming language of choice to return a result table to be used possibly in subsequent queries. If you write wrappers in a specific language, other languages probably cannot use the results very well. One of the nice things about a database is providing consistent data services to *multiple* applications. It is somewhat like SOAP, but integrated into the database engine.

[Oracle can do this in a couple different ways, because stored procedures can return result sets. I'm pretty sure that PostgreSQL also has this ability. Most of the real-world problems I've had implementing these sort of services have been related to client access APIs, rather than the database engine itself, so a data service wrapper (like a web service) is implemented on top of the database. This provides a simpler API without the need to much around with client/driver issues.]

: Some people still need portability, such as people who provide products that can be installed and interfaced with multiple databases. In this case there is a stronger argument against putting logic into SQL since you have to be so careful about which parts of SQL you can safely use.

But the OO "solution" is often to write your own database or database-like features. In that case, you might as well tie your product to an open-source database like MySQL or PostgreSQL (PostgreSql) so that you don't have to reinvent all those wheels. How is reinventing a database in app code better than tying your app to a specific open-source solution?

[This is a mischaracterisation. The OO solution is generally to write an API which provides consistent access to a number of SQL vendors. Features which can't be relied upon in the database are implemented in the layer. This is no different than any other sort of implementation-neutral layer. It (almost) never includes "writing your own database". ]

: SQL makes some things easy, but other things more difficult. Some people find SQL easy to work with, others find it horribly cryptic.

Although I generally prefer SQL over OO, I agree that SQL does stink in many ways. I would like to see a push to improve or overhaul SQL. SQL is hardly the pinnacle of relational languages. IMO, SQL is to relational as COBOL is to procedural. SQL was chosen over better alternatives partly because it was believed by IBM management at the time to be more "English-like" rather than programmer-friendly. More programmer-friendly approaches (like BusinessSystemTwelve) were rejected.

I believe in the power of relational. But, I also agree that it needs improvement. Most of the complaints against relational that OO fans use are related to specific vendors or specific relational languages. The OO hype has pulled away from R&D in relational that I think it deserves. If flawed relational is pretty good, improved relational should be able to fly even higher.