Yes! VERY! For example, what do I get if I do show plan or explain SQL on your example? How many can read that output and know if it's good or bad? Or know what optimizer is doing? (If you do a large web site... it's key. There is only one thing that will give you good results when it's in somone else's hands; and it has nothing to do w/ computers)My main point is... more Java people should MASTER SQL. Slowest part of J2EE is data access.Code genraters like you said that generate DAO / View based on columns are nice for marketing. Somone on the team better know what goes on.
We have differents POV and both manage to do our job, there is no problem so.AGREE..V
Please excuse me, but I am going to be persistent [sic] about my point here, and this may well be irritating to some people.
I have heard the same arguments put forward here about using and tuning SQL as I used to hear about using assembler decades ago. I remember the arguments about the adoption of C++ - that it would always be too slow, that hand-coded assembler was necessary for performance, and that a detailed knowledge of the register set for a processor was required.
Ok, it's not quite that bad, and I do feel that a knowledge of basic SQL (and relational theory) is certainly a good idea for Java coders, but I have to protest about your comments about the quality of SQL code generators. A HUGE investment has been put into O/R systems to ensure that the generated SQL is both high performance and tuned to the specific DB (just as in C++ compilers, a huge amount of work is put into optimising the resulting assembler).
I have a strong (and often unpopular) view that if you sit down in front of a specific DB and start to code a large project in SQL tailored for that DB you are storing up huge problems for the future.
First, suppose the next release of the DB has some dialect changes that improve performance. You are going to have to go through all your code and tweak it to handle the new features. If you use a quality O/R product, new releases of that product will have up-to-date knowledge of the DB and will deal with most of the optimisation automatically, and there will be minimal work for you.
Secondly, suppose the licensing scheme for the DB changes, (or company policy on tendering changes) and you are asked to provide a strategy for migrating your large application to an alternative supplier. Using an O/R product can mean that the migration could take only days or weeks as against months or years.
Thirdly, suppose you have to deal with a mixed supplier situation in which there are a variety of DBs installed. If you don't use an O/R, you will have to gain detailed experience of each DB. You can even have a heterogenous cluster of servers with different DBs.
Finally, using an O/R has the same sort of advantages as using Java: You can develop a product, and then allow the client to decide later on which platform and DB they wish to deploy. It's not going to be quite this simple, but to a large extent, this is true.
Note that using ANSI SQL is not a satisfactory solution, as you will not be able to use DB-specific features to gain performance. A quality O/R will know about, and use, these features.
So what is the answer? First, find out what modern O/R is really like - don't make out-of-date assumptions about how they work or about performance. Then, try out a high-quality O/R system, like Hibernate or one of the better JDO systems. Put work into tuning it, and learn the techniques to get the best from the product. Unlike with SQL, this experience is highly transferrable between different DBs. Only when you end up with very specific and serious performance problems, resort to direct SQL (most O/R systems allow this).