No more Blub for me, thank you, Vicar.
So you get people fetching thousands of records individually from the DB, modifying them in teh Java tier and then storing them again individually, instead of calling a single SQL update statement, for example.
[LEARNING bLOG] | [Freelance Web Designer] | [and "Rohan" is part of my surname]
Many programmers (not only Java programmers) know a lot about programming, but don't know a lot about relational databases.
[OCP 21 Professional Study Guide] [OCP 17 Complete Study Guide] [OCP 17 Practice Tests] [OCP 11 Complete Study Guide] [OCP 11 Programmer I] [OCP 11 Programmer II] [OCP 11 Practice Tests] [OCA 8] [OCP 8] [OCP 8 Practice Tests Book] [Blog]
"Take it from someone who has had to review 10-20 year old SQL queries, most of the time you wish you can throw them out."
Either way, you're ignoring the obvious benefits of having software that's completely free of SQL code...
No more Blub for me, thank you, Vicar.
chris webster wrote:Not trying to provoke a major conflict with all you good people at Javaranch, especially as I'm still learning lots of great Java goodness from all of you, but the above statement encapsulates a common experience I've had on several recent projects, and I'd like to see if others have had the same experience.
Deepak Bala wrote: The tools automatically converted the tables to classes and wrote the VO and DAOs for me.
Scott Selikoff wrote: Either way, you're ignoring the obvious benefits of having software that's completely free of SQL code.
[OCP 21 book] | [OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeanne Boyarsky wrote:I think lack of experience is a problem anywhere.
Jeanne Boyarsky wrote:
Why Java in particular? Because you are asking at JavaRanch? Because you've worked with Java developers? I fail to see why Java would have a bigger problem with this than .NET (which also as ORM frameworks.)
No more Blub for me, thank you, Vicar.
Jeanne Boyarsky wrote:Then we switched to simple queries that did one thing only and the network traffic killed us. We finished by batching them
However, it ties you to one database and requires you to split logic between the application server and database server. If your architecture already uses stored procedures, this is the typically the best solution
No more Blub for me, thank you, Vicar.
Paul Clapham wrote:
Jeanne Boyarsky wrote:I think lack of experience is a problem anywhere.
But Codd defined the relational database paradigm back in the 1970s. That's over 30 years ago. So why the lack of experience? It's hardly a new field which hasn't had time to attract practitioners yet.
[OCP 21 book] | [OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
chris webster wrote:So far as I can see, Java/J2EE is a great technology, but it should be just one tool in the toolbox. The problem is that many factors in Javaland seem to encourage a blind faith in the idea that all you need is Java. Which is roughly where I came in...
chris webster wrote:This concern about being tied to one database is often raised in Javaland, but how often does a company really shift its entire system from one RDBMS to another?
chris webster wrote: If you've encapsulated your SQL inside stored procedures, at least it will be easy to find and change it all in one place, and in the meantime you will have all the benefits of using the available tools intelligently. As for splitting the logic, some things are just much easier and more effective if you do them with SQL etc, so you're going to have to do this anyway.
[OCP 21 book] | [OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Jeanne Boyarsky wrote:
chris webster wrote: If you've encapsulated your SQL inside stored procedures, at least it will be easy to find and change it all in one place, and in the meantime you will have all the benefits of using the available tools intelligently..
I'm not anti-stored procedure. And we do use stored procedures - when doing something where it makes sense.
[OCP 21 Professional Study Guide] [OCP 17 Complete Study Guide] [OCP 17 Practice Tests] [OCP 11 Complete Study Guide] [OCP 11 Programmer I] [OCP 11 Programmer II] [OCP 11 Practice Tests] [OCA 8] [OCP 8] [OCP 8 Practice Tests Book] [Blog]
Scott Selikoff wrote:[I'm anti-stored procedure, only because 85% of the time I see them used incorrectly.
Personally, though, my issue with stored procedures is that its nearly impossible to move them between database platforms since the syntax isn't standard.
No more Blub for me, thank you, Vicar.
chris webster wrote:In case anybody is interested, there's a great talk by Rod Johnson on lessons learned from the evolution of Java and J2EE,
Distributed computing is hard, and I don't think we've found a good solution yet. Today's most widely adopted web technologies are just as ugly and complex.Pat Farrell wrote:
chris webster wrote:In case anybody is interested, there's a great talk by Rod Johnson on lessons learned from the evolution of Java and J2EE,
I agree, great talk, well worth the time to view it.
Plus, he properly slags both Corba and J2Ee, which really deserve to be properly recognized as complete disasters.
Frank Silbermann wrote: Distributed computing is hard, and I don't think we've found a good solution yet. Today's most widely adopted web technologies are just as ugly and complex.