Approach to searching

Question

Hi Everyone
We're building a web site here that implement both basic and advanced searching functionality. Basic searching is essentially searching on various attributes of on table and advanced searching is across many tables (even possibly 20-30 tables).
We're using ODP.NET to access the Oracle database and I'm required to come up with a strategy to implement this search functionality.
My first question is Stored Procs vs. Inline SQL? Which to use? I'd like to use procs but given the potential for a huge number of search parameters, I just don't know whether store procs can take that many input params? Inline SQL would be ok since we could build some SQLBuilder code to assemble the various components of the statement (to avoid SQL injection, errors etc) but I'm not sure if this is best practice of if the performance on this is just gonna kill the app.
The other alternative i was thinking was making views of common search joins (say employee with department or something) so that these kind of joins are already done for the user so that can improve performance.. is this also common practice?
We don't have the resources to build another searching database with denormalised views of the entire database but any input into things that I should/shouldn't do would be greatly appreciated.
cheers

Answer 1

Hmmm. So basically what you are doing is re-writing the functionality of something like Business Objects or Oracle Discoverer. Have you got a business case to prove that you can write something cheaper than the cost of licencing one of those products?
Next on the list: performance. Dynamically assembling oodles of queries is likely to knacker your system because:
(1) dynamic queries take resource to assemble;
(2) your users don't know SQL or how the database is assembled and consequently will "write" bad queries.
I think it's significant that tools like BO and OD now insist on us building a meta-model or universe. They don't let us inflict the raw database structure on the users, and vice versa.
Almost every project I've ever worked on has had as a requirement "we must be able to write our own reports". How many users actually avail themselves of this facility? Almost none. And those that do usually have one or two bespoke reports that they run once a month. In short, it would be much cheaper to seek out those troublemakers and put their darlings on the developers' To Do list.
But, if you must, and of course, we all know what users are like...
Start with the Basic Search. Don't build it in the middle tier, put it in the database. Use parameterised functions to return REF CURSORs; the limit on parameters is well over 1000 and you don't want to handle more than that! Make sure your generated code uses bind variables.
Once you've got that working correctly, move on to More Advanced Search. Don't allow the users to search any combination of tables they fancy. Present them with choices, which map to more parameterised functions returning REF CURSORs. Use views or build the joins dynamically, as you wish. Add a button to your application that says, "Is there a report missing from this list? Tell us what you want to see!"
This may not be what you wanted to hear, nor what your users think it is they want, but it is a proven, reliable approach.
"The enemy," retorted Yossarian with weighted precision, "is anybody who's going to get you killed, no matter which side he's on." Joseph Heller, Catch-22
Good luck, APC