Tuesday 2 March 2010

Opinions of the masses

When to hard-code is always a big question when it comes to programming languages. SQL certainly has a few exceptions. PL/SQL - not so much.

So when it comes to hard coding within PL/SQL, I'd say I'd agree with Steven Feuerstein. I agree with most of his standards, and his article on this is concise.

In the other corner, Jeff Kemp raises an excellent point about hard coding in SQL. We worked on a complex project together once where hard coding of certain literals was important - and done correctly. Commenting never goes astray. This example is way out of context so it's hard to illustrate, but if I may:
SELECT something
FROM my_table
WHERE entity_type = 123 /* XYZ type */
AND entity_id = :my_bind_parameter;
Where entity_type contains the value that will never change, and hence Jeff's adage - "do not change this code"

Also note Narendra's comment on Jeff's article - be very careful about the use of cursor_sharing = FORCE in these scenarios.

I just wanted to highlight these two related articles.

1 comment:

Jeffrey Kemp said...

I largely agreed with Steven too, but took issue with his statement "Almost nil" - regarding the likelihood of not getting requirement changes (i.e. make everything a constant because you WILL have to change its value).

So, I'm almost in the same corner, maybe just next to Steven, taking the occasional jab :)