This post originated from an RSS feed registered with Java Buzz
by News Manager.
Original Post: Fear of SQL: Will We Ever Learn to Cope?
Feed Title: Java Today
Feed URL: http://weblogs.java.net/blog/editors/index.rdf
Feed Description: Java Today on java.net
Dustin Marx fears that he may suffer from some mild phobias (fear of crowds and sermons -- and perhaps the fear of being phobic?) -- but, to Dustin, the relatively common fear of SQL that he observes in the software development community seems quite irrational. So he says, in his latest software development cogitation, Sqlphobia: The Irrational Fear of SQL:
The Phobia List provides an exhaustive list of phobias. Although it is difficult for many of us to understand or relate with many of these phobias, some are all too easy [for] me to understand. For example, I fear that I suffer at least mild cases of demophobia (fear of crowds) and homilophobia (fear of sermons). However, one fear that I see with a relatively high degree of occurrence in the software development community is the seemingly irrational (to me) fear of SQL.
Dustin hits the nail on the head, when he notes:
There have been numerous attempts at abstracting away or hiding SQL from the developer. The object-relational mapping (ORM) approach is probably the largest of these efforts in terms of person hours invested. This approach attempts to allow developers to focus on objects and their mappings to relational database structures (such as tables and columns) with the hope that the developer will never (or at least much less often) have to read, write, or maintain SQL.
The question, though, is: why? Or, perhaps, why so vehement an effort? If you're developing a database application, isn't it important to understand the nature of database tables and queries?
It's one thing to look back to user interface programming from decades ago, and say -- OK, you no longer have to draw each pixel to create your window, because now you can just send this snazzy function a set of parameters and it will do all the low-level work for you. There, you're just providing an interface to a function that performs a task that must be repeatedly performed in the exact same way (drawing pixels to create a UI window) in any modern interactive application.
With SQL, I think you're dealing with a different beast. Each query is unique. Furthermore, there are multiple paths to accomplishing the same objective. And how you do it makes a difference. Even if your query satisfies the needs of a client application, with SQL you're actually always working on the back-end, the server side, where performance matters. Where performance matters, abstraction is always a potential problem. One size does not fit all where performance is concerned. So, an abstraction that lets you set switch-like parameters on an object that "controls" your database querying poses significant performance risks in a scaled system.
But that's all my view, and, like Dustin, I don't have Sqlphobia. To me, it's just another language that's highly useful for me to know somewhat (since the bulk of my software development work in the past 15 years has been in a Data Center environment where SQL -- first Postgres, now Oracle -- has been a backbone of the processing). Furthermore, it's highly useful for me to understand at least the basics of tables, how JOIN works, etc., if I want to be able to legitimately consider myself worthy of the title of highly-experienced software engineer / architect.
SQL is just another programming language! Though it's a very specialized one.
Getting back to the ORM SQL obfuscation tactic, Dustin points out:
But what about today? What about Java EE 6 and JPA? Dustin says:
Overall, I'm a fan of JPA as I hope I made clear in my article Basic JPA Best Practices. I like the ability to relatively easily tie my normal Java objects into the transaction support of the supporting application server. Also, I think its advantageous to have a standardized approach to ORM rather than using a proprietary solution such as pre-JPA Hibernate.
However:
With all the positives of JPA, I still find there are times when it either is more than I need or when the impact it has on my object design is too great to justify. Furthermore, I have found the ability to be able to read SQL invaluable in debugging problems with my code that uses JPA implementations. In other words, I still need to know and be comfortable with SQL, even when using JPA implementations.
As always, when Dustin Marx tackles a topic, he tackles it from all sides, including the four cardinal directions, and from the top (high-level overview) -- then he burrows into software engineering history and mounts an attack from underneath as well. Reading Dustin's Software Development Cogitations and Speculations is always a worthwhile venture. He does a lot of interesting, and sometimes quirky, experimentation with Java, JVMs, etc.
If your current work involves SQL, or if you have a history of phobia related to SQL, or if you just want to read some really interesting "cogitations and speculations" about "Sqlphobia" -- take a few minutes to read or at least browse Dustin Marx's Sqlphobia: The Irrational Fear of SQL. It's not that scary. I promise! (your non-SQL-phobic editor says with a evil grin!)
This tutorial is for people who want to run a JAX-WS example (Endpoint + Client) in just five minutes. What you need to run this example: 1. JDK 1.6; 2. Eclipse; 3. Be Excited ;) ...
If you are using Ant 1.7.1 for developing Web Services with JAX-WS/JAXB, I suggest you to move to the latest version Ant 1.8.0. JAXB/JAX-WS rely on package level runtime annotations for lot of things. For ex: JAXB relies on the @XmlSchema annotation in package-info.java and uses it for binding Java data types to XML schema types. You might be puzzled to see that the mappings are not as expected. I wasted almost half a day trying to figure out if there was some regression in JAX-WS/JAXB as I was suspecting Ant the least. A bug in Ant 1.7.1 javac ant task, makes it not compile package-info.java. This is a serious regression...
Administrators are always looking for a more effective, easier to use, and less time consuming tool to use as the interface sitting between them and what they supposed to administrate and manage. GlassFish provide effective, easy to access and easy to simple to navigate in administration channels which cover all day to day tasks that administrators need to perform. But when it comes to administration, administrators usually write their own shell scripts to automate some tasks; they use CRON or other schedulers to schedule automatic tasks, and so on to achieve their own customized administration flow. By using GlassFish console, it is simply possible to use shell scripts, or CRON to further...
I am working on rewriting a set of labs for our intermediate students at SJSU. Version control is something that everyone with a CS degree is pretty much expected to know these days, so I thought of digging up an old Subversion lab from my open source programming class. But distributed version control systems such as Mercurial and Git are getting all the love these days. Some people said that it is actually easier to teach Mercurial than Subversion. This seemed unintuitive--wouldn't it be harder to deal with a bunch of repositories instead of having just one centralized one? Actually, I now see the point...
ranjithjavanet has a question regarding Glassfish v2 alternatedocroot - will DAS sync it?: Using Sun Glassfish Enterprise server v2.1.1 I am using "alternatedocroot" via sun-web.xml for my web application to abstract out static content from actual deploy-able code (EAR/WAR) What I have is a cluster of two server instances...
In the Java 3D forum, andimb asks about putting a Coordinate System or Object in a Canvas corner: Hi, is there a possibility to add an coordinate system or object at a corner of the canvas, e.g. lower left corner? The object should rotate but not zoom or move like all other objects visible on the Canvas. The transformation...
The application menu button in the ribbon component from Flamingo component suite is a big round button in the top left corner of the ribbon. It is not a direct replacement for the usual application menu bar, but rather a place to hold actions that (as a general rule) do not affect the visual content of the document – such as saving, printing, sharing etc. Prior to version 5.0, the ribbon frame...
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
