Related Entries

Jython is great
Oracle 9i skills and DB2
XP and SQL
Jython zxJDBC rocks!
Quick Start: Firebird on Windows

« Two sides of a fence
» Quick Links

Respecting SQL

SQL is getting unfashionable among Java crowd. It doesn't have to be - you get reliability, maturity and familiarity with your data, using SQL.

Jack D. Herrington: “Have a Little Respect for SQL Databases As we race towards better object technology, some people seem content to put relational database systems out to pasture—for no good reason. ”

Via Christoph C. Cemper

Amen! I use RDBMS heavily. I use Oracle 90% of the time. Rest is divided between MS-Access, MySQL, PostgreSQL and FireBird. Fact that there is a disconnect between OOAD and RDBMS theory is well known. But, is it such a bad thing? I’ve sat through couple of J2EE marketing pitches where the main selling points were portability, scalability, database independence and ease of development.

For a software product development company, database independence might matter. However for a product consumer, like an internal IT department, the needs of database independence is usually lost. There are significant reasons to choose a database platform to host the corporate data. Sensible organizations choose a development platform that works best with what holds their data - and not change the database to suite what developers crave for.

Ease of development is usually explained as developers don’t need to write SQL! Personally, I would prefer writing one useful SQL to 100 lines of Java code. SQL is intended for processing data. It does that very well. Couple of developers who prefer to avoid SQL told me once that tuning SQL queries are too hard compared to using profilers for say, Java or C++. I think it is much easier to profile SQL execution plan than profiling other languages. I guess it is a different mind set.

I think a good software team needs a mixture of both. Like Andrej mentions, refactoring (PL)SQL is hard. Most database programmers are too concerned about data - rightly so. Most non-database programmers are very concerned about programming style, unit testing, in-memory data management and would like to consider databases as a convenience to serialize objects to. Without data, programming is useless in an enterprise. Similarly, without programming expertise, data is usually inaccessible. Good software teams need equal measure of both worlds to succeed. Repeating "complexity kills" every day might also help.

Microsoft seems to be pusing SQL Server with .NET instead of evangelizing Object-Relational frameworks. Practical.

Off topic notes about MS Access: This curse of civilized world* did not affect me when I worked for software engineering firms. Since I joined a non-IT firm’s IT department (the idea was to learn what users wanted, first hand), there is no escape from Access databases. Every one starts by creating an Excel spreadsheet, because almost anyone can do that without seeking help from IT department. Soon, they end up needing reports. Quick solution is to move to Access and make some reports. So far so good. Now, when the database becomes useful and known, there is a need to make it web enabled. Now comes the struggle to get it back and forth between enterprise Oracle instances and desktop Access. It is no fun, but still, Access fits a nice niche. Personal Oracle and Oracle Lite are well and good, but an average IT department cannot roll it out to the whole enterprise.

Ofcourse, for every 10 Access users, there is one smart Macintosh user who gets more things done much more quickly using FileMaker Pro. Before I joined my current job, I was almost unsympathetic to the existence of desktop databases. I think this is a market Oracle hasn’t tapped into enough. I will easily pay $500 for having desktop Oracle database that won’t ask me questions about instance names or TNS configuration and comes with a decent front end for schema and data manipulation.

*Curse of civilized world - that is how some database engineers who work with enterprise databases like to call Access. I used to believe that too. Till I got wiser and figured out it is far more easier for most users to make something that works _for them_ in Access than listen to most IT propellerheads.

  1. I can't agree more on *most* of your comments regarding RDBMS. My only question is, have you actually seen good filemaker databases? I got sold on filemaker on the windows platform based on the idea that you can quickly whip up a database (which you can) but i found that when you tried to turn it into something more robust it became extemely unwieldy. The windows version, for example, kept open windows for every table open (in my case 10 or so) and it was a visual nightmare...


    Posted by: Maniac on October 13, 2003 10:46 PM
  2. I've seen some good ones on Macintosh. The versions I used (4.x) on Windows was not as good. Robustness is not its plus point, but it makes the route from idea to implementation, a short one for non-IT folks. It can even do web publishing very quickly, as long as you don't bother about security and scalability.

    Posted by: Babu on October 14, 2003 05:55 AM
  3. Defintely agree with the thrust of the above. RDBMSs are one of the few fields in s/w development with a firm theoretical foundation (Set theory). The difficulty of mapping objects to an RDBMs seems to me an indication of the issues with the object paradigm(s) than RDBMSs.

    Re. MS Access - great to put an accessible tool in the hands of end users, but there is really no excuse for the dismal UI ("Where do you want to hide your code today?"). I abandoned DataEase for DOS 15 years ago now, but have yet to find as accessible a product for *END USER* RDBMS development. Zope over Firebird is the best I can come up with for now, but the (lack of) documentation undermines that preoposition...

    Posted by: PhilK on May 29, 2004 08:51 PM