Etbin wrote:This subject has always been a topic of discussion. Been 5 years but the memories still remain fresh!!
Thank you for the link.
Each time I'm discussing the matter I remember having read it suggesting to search for Feuerstein on Ask Tom.
It's between favorites now to have the link at hand as things are very much alike to Tom's disagreements and not getting any better.
Billy Verreynne wrote:But most experts including Tom Kyte consider him one of the best pl/sql developer around.
Well, Steve is then wrong if he thinks SQL needs to be limited in PL/SQL. As he is also wrong, IMO, when it comes to coding standards and dealing with the issue of scope.
Rahul India wrote:He's not the only PL/SQL developer around.
But most experts including Tom Kyte consider him one of the best pl/sql developer around.
Billy Verreynne wrote:When the app developer uses OCI, JDBC or some other "client" software, the interface tells him how to do bind variables, but not why. No bind variables (in an OLTP environment) = SQL injection risks and scalability problems due to excessive parsing. Those are database fundamentals, not OCI or JDBC fundamentals. Only the application developer can solve a parsing problem.
Stew, using bind variables in this respect is more of an issue of how to use the OCI (Oracle Call Interface). Does not matter whether the client makes a SQL or PL/SQL call - bind variables need to be used.
One of the best examples I have seen of this was back with Oracle 7.3...The client app (think they used PowerBuilder back then) only made use of PL/SQL calls and from an app developer perspective, nothing need to be understood of the database, beyond that.Powerbuilder is/was a client-server product. The user had his own session with his own identity in the database: since the session stayed "his" between calls, the user could do multiple fetches from the same cursor and updates could be done with pessimistic locking.
Stew Ashton wrote:Agree wholeheartedly. But the exact opposite has been happening over the last decade. Beans. Hibernate. Etc.
In the developer community as a whole, we need lots more knowledge of the database, not less.