Comments on: Storing the SQL queries in the database http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/ Tango, photography and whatever's bleeding edge Wed, 17 Mar 2010 02:53:04 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Louie http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/comment-page-1/#comment-431579 Louie Fri, 01 Jan 2010 08:12:40 +0000 http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/#comment-431579 I have the same idea some 5 years ago to store SQL within the database itself for my programs (but I didn't really implemented it yet :P). This is because it usually takes too long to go through the deployment cycle if I need to add / modify my sql statements. However, I think it is the best to use it only in reporting related things (as those data input parts actually requires a lot more of validation, business logics, etc). My idea is quite similar to yours: a table of sqlID/sql queries/parameter list/version#. In order to make it work in reporting environment, I am assuming my queries operates in a set of predefined parameters, e.g. %CategoryID%, %ContactID%, %OrganizationID%, %StaffID% etc. And in the UI, we always know what these parameters refer to and how to fill in the dynamic queries in a well controlled manner -- e.g. StaffID is always the login user or select from a drop down, or user can select from a list of categories from radio buttons. etc. As I use dot net, the parameters will be maintained in a name value pair array (maybe a dictionary type as well) 1 challenge is how you configure the parameters to an FieldName IN (a,b,c) type. I think you need to define a different #ParameterList# parameter which evalues to "Field in ('a','b','c')" or "Field in (a,b,c)" Louie :) I have the same idea some 5 years ago to store SQL within the database itself for my programs (but I didn’t really implemented it yet :P ). This is because it usually takes too long to go through the deployment cycle if I need to add / modify my sql statements. However, I think it is the best to use it only in reporting related things (as those data input parts actually requires a lot more of validation, business logics, etc).

My idea is quite similar to yours: a table of sqlID/sql queries/parameter list/version#.

In order to make it work in reporting environment, I am assuming my queries operates in a set of predefined parameters, e.g. %CategoryID%, %ContactID%, %OrganizationID%, %StaffID% etc. And in the UI, we always know what these parameters refer to and how to fill in the dynamic queries in a well controlled manner — e.g. StaffID is always the login user or select from a drop down, or user can select from a list of categories from radio buttons. etc.

As I use dot net, the parameters will be maintained in a name value pair array (maybe a dictionary type as well)

1 challenge is how you configure the parameters to an FieldName IN (a,b,c) type. I think you need to define a different #ParameterList# parameter which evalues to “Field in (‘a’,'b’,'c’)” or “Field in (a,b,c)”

Louie :)

]]> By: Abhishek http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/comment-page-1/#comment-180340 Abhishek Tue, 27 Nov 2007 20:49:20 +0000 http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/#comment-180340 Hi, How can i put substitution varable into the Access Database sql query, It will ask user to give the prompt answer Hi,

How can i put substitution varable into the Access Database sql query, It will ask user to give the prompt answer

]]> By: Peter http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/comment-page-1/#comment-576 Peter Sun, 02 Apr 2006 14:22:27 +0000 http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/#comment-576 Good question. If one were to start using stored procedures, and then add logical naming of the procedures, add web-based editing with versioning, add a mechanism for passing a variable number of parameters and encapsulate everything in a piece of code, one would probably arrive at something quite similar. My system would work with a sissy database like Access, but once you have a more mature RDBMS (SQL-Server, mySQL, Oracle, Postgres), using stored procedures to implement it is obviously a best practice. But it's more than just that. Good question.
If one were to start using stored procedures, and then add logical naming of the procedures, add web-based editing with versioning, add a mechanism for passing a variable number of parameters and encapsulate everything in a piece of code, one would probably arrive at something quite similar.
My system would work with a sissy database like Access, but once you have a more mature RDBMS (SQL-Server, mySQL, Oracle, Postgres), using stored procedures to implement it is obviously a best practice. But it’s more than just that.

]]> By: LVB http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/comment-page-1/#comment-555 LVB Sat, 01 Apr 2006 18:03:45 +0000 http://blog.forret.com/2006/03/storing-the-sql-queries-in-the-database/#comment-555 What's the essential difference between your idea and stored procedures? I mean, which of your 5 advantages cannot be obtained by applying the standard stored procedures approach? What’s the essential difference between your idea and stored procedures? I mean, which of your 5 advantages cannot be obtained by applying the standard stored procedures approach?

]]>