Article:		Stored Procedures for Java Programmers
Subject:		Too Generalized an Article.
Date:		2003-08-14 11:51:10
From:		anonymous2
I agree with the use of stored procedures for modularization and performance reasons but the article was so general, it's for complete beginners. You could have gone into a little more detail: "Writing stored procedures has better tool support than writing embedded SQL in Java -- most editors even provide syntax coloring!" - What's you definition of "better"? "Stored procedures can be tested from any SQL command line, making debugging easier!" - What debugging tools are you using? Debugging stored procedures has been the biggest pain in the butt I've run into due to lack of debugging tools from IDE's. You don't even have extensive logging support from the procedure (ex: log4j, other logging tools). You still wind up writing to the console from the procedure.

Showing messages 1 through 2 of 2.

• Too Generalized an Article.
  2003-08-21 13:17:36  anonymous2 [View]
  
  
  (* I agree with the use of stored procedures for modularization and performance reasons but the article was so general, it's for complete beginners. *)
  
  As a complete beginner (to stored procs, not Java or basic JDBC/SQL), I actually appreciated the generality. I don't tend to use oreillynet articles as in-depth sources, but rather I read them as a broad overview of something that I can read about in more detail in one of ORA's books, if I'm interested, and also stay away from certain subjects (such as AOP etc) that don't interest me. (No offense to oreillynet article authors.)

• Too Generalized an Article.
  2003-08-14 12:22:40  nferrier [View]
  
  
  thanks for your comments.
  
  By "better" I mean that there is some. If you use TOAD or TORA you get syntax colouring and all those kinda things. TORA has a half decent PL/SQL debugger. Even using Emacs with SQLPLUS or PSQL gives you syntax colouring and the ability to test things line by line. Compare that with writing SELCT statement embedded into Java strings.
  
  Yes, you can still test the SQL statements before you embed them, but you can't test PreparedStatement's for example... it's much easier with procs.
  
  As for logging I agree that console logging and DBMS' don't go together at all. I always use a table with a timestamp and a wide varchar. I think that's a fairly widespread technique.
  
  I know some people don't like using a log table because it takes some setup. But I've never understood that, the time taken to create a table for this purpose is tiny.