Svein Erling Tysvaer wrote:

> There's nothing wrong with mixing approaches. I agree that two or three parametres would be about maximum if you wanted to make the best

> possible query in all circumstances. But what about making sure that at

least one indexed field is specified completely so that the index can be

used?



and
PenWin wrote:

> 2) Using several different queries and branching between them according to

> the parameter is only usable if you have two or three parameters at most -

> the number of required queries grows too quickly.

I agree that 'pre-hanging' queries and writing complicated "if - then - else" logic to select between them can get pretty terrible, pretty fast. It seems to me that it would be much better to generate the query dynamically, based on which fields are selected and filled - treat the fields as a control array (if the language you're using has something like that), and simply step through it - if a field contains input, add that field to the query, otherwise not. This approach adds flexibility - if you add or remove fields from your input form in the future, you don't need to change the logic.

Again depending on your application language, "field" objects generally have a few user-available properties - at design time, you could set a flag to specify whether this field refers to an index or not (pace Set!); another property can hold the actual query fragment to be added to the generated query (so the main logic doesn't need to know what's in the field).

I would much rather spend a little time setting this up in the application than add even a second to my users' response time. They get so impatient...





____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097