in reply to Navigating the plethora of SQL modules

Parking your SQL in stored procedures will fullfil the 'someplace else' requirement if your db engine can handle them. If you are using MySQL or Access then you're out of luck.

Stored procedures have the additional advantage of boosting performance. They also tend to be a bit more secure than dynamic SQL.

Hanlon's Razor - "Never attribute to malice that which can be adequately explained by stupidity"
  • Comment on Re: Navigating the plethora of SQL modules

Replies are listed 'Best First'.
Re: Re: Navigating the plethora of SQL modules
by dragonchild (Archbishop) on Nov 25, 2003 at 15:25 UTC
    How would I do the dynamic building of the statement in stored procedures?

    ------
    We are the carpenters and bricklayers of the Information Age.

    The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

    ... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      The specific way of handling dynamic sql via stored procedures varies depending upon what flavor of sql you are using, but they boil down to eval'ing statments inside of the procedures or if-else blocks. Be forewarned, though, that eval'ing inside of stored procedures causes a performance hit.

      To get the most optimal performance, though, it would be best to eliminate the dynamism, if you can do so w/o creating a mess. If your dynamic cases really boil down to a manageable set of statments, then it would probably be best to write/generate separate procs for each!

      If, for example, the following Perl/SQL stement:

      my $statment = "SELECT COL_1, COL_2 FROM $table";

      is really only ever going to give you three SQL statments:

      SELECT COL_1, COL_2 FROM TABLE_1 SELECT COL_1, COL_2 FROM TABLE_2 SELECT COL_1, COL_2 FROM TABLE_3
      then you may be better off creating three procs (pseudo-SQL follows):

      CREATE PROC get_stuff_table1 AS SELECT COL_1, COL2 FROM TABLE1; CREATE PROC get_stuff_table2 AS SELECT COL_1, COL2 FROM TABLE2; CREATE PROC get_stuff_table3 AS SELECT COL_1, COL2 FROM TABLE3;

      This can get really out of control, though, if you are going to end up many procs. If you are going to end up with more than a handfult then you should consider generating them. Of course, this process can be eased if you generate your procs with a nice language such as, oh... umm.. Perl.

      Hanlon's Razor - "Never attribute to malice that which can be adequately explained by stupidity"