Catalogue of SQL and PL/SQL bad practices: Call for participation

Question

I started compiling a list of Oracle SQL and PL/SQL bad practices, with the intention of producing a comprehensive catalogue of common and recurring programming mistakes, that can be used as a check-list for code reviews or given to junior developers. I have identified about 30 bad practices so far. For each bad practice, I provided a list of symptoms in the code, an explanation why it causes problems and a list of preferred solutions.
My goal with this list is primarily to start a discussion about similar recurring issues that other people have noticed. That discussion should lead to a more complete list which the community will then be able to use, hopefully, to learn something from the mistakes of others and to produce better code.
I would really appreciate your feedback - if you are interested in discussing these practices we can either do it in this forum, or start a separate mailing list.
You can download the first version of the catalogue in PDF form from http://gojko.net/effective-oracle
gojko adzic
http://gojko.net

Answer 1

exception handler (already covered), the philosophy
behind not using stored procedures, and having beenHi riedelme,
I'm not advocating not using stored procedures, but I am advocating not using exclusively stored procedures. I've seen that approach often, typically with people coming from SQL server or Oracle forms backgrounds, I never could understand the reasons behind it. Even for a simple select or update, they would write a stored proc that wraps the call and then require the client to execute a stored proc.
I think that views are much better for getting the data out of the database in general, and forcing people to use stored procedures with ref output cursors makes little sense. If the only possible interface is a stored proc, then one proc must be created for every required combination of data and every required filtering or grouping method, so there is much much more code in the database, and more code means harder maintenance.
If client apps can get data out using views, then they can join them with other views, filter or group the data as they require, which means that there is a lot less code in the database to maintain.
My other problem with stored-proc only approach is when people wrap simple insert/update/delete commands into a stored proc. Again, I'm not advocating using complex instead-of triggers to implement workflows and forcing people to use views, but I simply don't see any benefit of implementing a stored proc to do a simple update. I see a bad side of it because a stored proc needs to be implemented for every combination of columns that a client may need to update and every criteria that can be used for that. If a client is allowed to update a view, there is much less code in the database.
Views are, in my experience, also a lot easier to maintain and optimise without downtime because they can be revalidated without causing any problems to currently connected clients, where revalidated stored procedure or package will throw an exception the first time a connected client that had called it before calls it again.
If I'm missing something, please tell me. I'd really love to understand why someone would build a client API exclusively from stored procedures.
So far, I've been given explanations that it is for security purposes, or for performance. I don't know of any security restriction that can be implemented on a stored procedure or package that cannot be implemented with a view, and if bound variables and statement caching is used, sql statements don't suffer from sql injection and support pre-compilation.
Again, i'm not advocating throwing stored procs completely out, i'm against using them exclusively and throwing out any chance of SQL access.
gojko adzic
http://gojko.net