How to rewrite dynamic SQL built using IF clauses, as static SQL?

Question

Hi folks
I have some Dynamic SQL that I would like to rewrite as static.
The original PL/SQL code contains a number of IF clauses that I would normally replace with CASE statements in the static code, but I am wondering if I'm doing it the best way as although it works, I am not that happy with it for reasons described below.
[Please excuse any remaining syntax errors, I have tried to reduce them but we have no Oracle on our internet network and I can't CutnPaste from the dev network.]
So...
An example of what I would normally do.
A silly example, I admit, but it's just for demo.
Original Dynamic Code:
PROCEDURE GET_EMP_NAMES(p_job_title  IN VARCHAR2 := NULL
                       ,p_car_class  IN NUMBER   := NULL
                       ,p_REF_CURSOR OUT CURVAR)
  Purpose: Provide names of all employees.  But if MANAGERS only is requested,
  then limit the result set to those employees with the car class specified.
  Fields in table emp: first_name, fam_name, car_class(NUMBER)
AS
  v_str VARCHAR2(1000);
BEGIN
  v_str := 'select e.first_name, e.fam_name FROM emp e WHERE 1=1 ';
  IF p_job_title = 'MANAGER' and p_car_class IS NOT NULL THEN
      v_str :=  v_str || ' AND e.car_class = ' || p_car_class;
  END IF;
  OPEN p_REF_CURSOR FOR v_str;
END;My usual rewrite:
BEGIN
  OPEN p_REF_CURSOR FOR
    SELECT e.first_name, e.fam_name
      FROM emp e
     WHERE e.car_class =
                      CASE WHEN p_job_title = 'MANAGER' AND p_car_class IS NOT NULL
                             THEN p_car_class
                           ELSE e.car_class
                       END;
END;My problem with this is that some employees may have an e.car_class of NULL.
In this case the WHERE clause will evaluate to NULL = NULL, and so they will not be included in the result set.
So I usually defend with NVL() and some fictive constant for the NVL result, ie:
AS
  k_dummy_val CONSTANT NUMBER(20) := 56394739465639473946;
BEGIN
  OPEN p_REF_CURSOR FOR
    SELECT e.first_name, e.fam_name
      FROM emp e
     WHERE NVL(e.car_class,k_dummy_val) =
                    CASE WHEN p_job_title = 'MANAGER' AND p_car_class IS NOT NULL
                           THEN p_car_class
                         ELSE NVL(e.car_class,k_dummy_val)
                     END;
END;But now I have had to decide what to use for k_dummy_val. I need to choose some fictive number that is not and will not EVER be used as a car class. This is a problem as I do not know this.
So this makes me think that my technique is incorrect.
Do you have any suggestions?
Many thanks
Assaf
Edited by: user5245441 on 03:55 24/04/2011

Answer 1

Hi,
Assaf wrote:
... if I were to do the following then it would be a mess, right? Barckets are needed and if I have many such conditions and make a mistake with the brackets, then... :(Brackets may be needed, but they're a good idea even if they are not needed.
WHERE     p_job_title     != 'MANAGER'
     OR     'X' || TO_CHAR (car_class)     
           = 'X' || TO_CHAR (p_car_class)
AND   p_yet_another_param != 'SOMETHING ELSE'
     OR     'X' || TO_CHAR (another_field)     
           = 'X' || TO_CHAR (p_another_param)What do you think?Using parenetheses, that would be:
WHERE     (   p_job_title     != 'MANAGER'
     OR     'X' || TO_CHAR (car_class)     
           = 'X' || TO_CHAR (p_car_class)
  AND   (   p_yet_another_param != 'SOMETHING ELSE'
     OR     'X' || TO_CHAR (another_field)     
           = 'X' || TO_CHAR (p_another_param)
     )I find this clearer than CASE expressions, but I won't be maintaining your code.
This is one place where implicit conversions won't hurt you. Both operands to || have to be strings. If you use a NUMBER as an operand to ||, then it will be implicitly converted to a string. Usually, it's better to make this clear by using TO_CHAR, and converting the NUMBER to a string explicitly, but in this case you might gain clarity by not using TO_CHAR.
Put comments in your code where you think they'll help someone to read and understand it.
WHERE
     -- p_car_class only applies to MANAGERs
     (   p_job_title     != 'MANAGER' 
     OR     'X' || car_class
           = 'X' || p_car_class
  AND   (   p_yet_another_param != 'SOMETHING ELSE'
     OR     'X' || another_field
           = 'X' || p_another_param
... I avoid dynamic whenever possible, leaving it for use only in situations where things such as Table Names are unknown at compile time. I find it complex and error prone, and especially difficult for another developer to support at a later date.I agree. I agree especially with being concerned about the developer who has to modify or debug the code in the future, regardless of whether it's you or another.