Talk:SQLJ

> It is more efficient than JDBC since the SQL statements are parsed and the access paths are optimized at compile time rather than runtime.

Ridiculous. SQLJ is simply a precompiler syntax. In Oracle, it's like all other precompilers. The ONLY difference, w/r to compiling, is that SQLJ, since it is a precompiler, will check the syntax is valid. It does NOT optimize at this point, since there is no way to save the optimized plan (other than manually creating a stored plan). So both SQLJ and JDBC will be parsed and compiled the wsame way at run-time.

> It provides better authorization control: Authorization can be granted to programs rather than users.

== What the hell is this about????? == ?

- SQLJ programs are easier to write and to maintain. They also tend to be shorter than equivalent JDBC programs.

I would like to know in what they are easier to write and maintain? The syntax is nearly the same as plain SQL and the statements are tighly coupled in the Java code which in my sense make the program far less easy to maintain. Any change in your SQL will need a full build of your application like for plain SQL, if this is ease of maintenance I am not living on the same planet.

- It is more efficient than JDBC since the SQL statements are parsed and the access paths are optimized at compile time rather than runtime.

I think this is marketing bullshit only, except checking the syntax at compile time there is nothing that will allow you to especially optimize access paths.

- It provides better authorization control: Authorization can be granted to programs rather than users.

Like the previous user, I would ask you what are you talking about??? SQLJ does not manage anything like that in my sense

- Potential performance problems, such as inefficient queries due to a bad access path, can be identified at development time.

Well if your query has bad access path it won't be an inefficient query but an erroneous one...

- There is no SQLJ support for most of the common persistence frameworks, such as Hibernate.

I really don't see the point here to be able or not to use SQLJ with Hibernate as these two have a tottaly different goal.

66.131.36.87 22:34, 1 March 2007 (UTC)[reply]

I have largely rewritten the advantages section to remove unsourced opinions. Jon 13:51, 30 March 2007 (UTC)[reply]