Using stored procs for searching / reporting
From: PS <myspameater_at_yahoo.com>
Date: 21 Jan 2002 11:33:07 -0800
Message-ID: <e86bec3.0201211133.3763f4bc_at_posting.google.com>
I have an application that has a search panel where users can enter things like date ranges, invoice numbers, etc. I'm wondering if it would be 'good design' to make a stored procedure that took search criteria from the user and pieced together the query to run within the procedure, vs. granting read-only access to the table and having the application itself piece the sql together.
Date: 21 Jan 2002 11:33:07 -0800
Message-ID: <e86bec3.0201211133.3763f4bc_at_posting.google.com>
I have an application that has a search panel where users can enter things like date ranges, invoice numbers, etc. I'm wondering if it would be 'good design' to make a stored procedure that took search criteria from the user and pieced together the query to run within the procedure, vs. granting read-only access to the table and having the application itself piece the sql together.
I generally don't like embedding sql in applications because database schemas tend to change, and trying to track down applications with outdated sql is not fun. But how else do you allow reporting / searching on your database?. Only other way would be to create a view and have apps search on that, but then you're still stuck sending lengthy sql statements across the network. Received on Mon Jan 21 2002 - 20:33:07 CET