The way I designed it so far, the users actually don't need to know the structure of the database. I present them with a web form that contains select boxes for tables, fields, operators and even sometimes values. The table names are comprehensive enough so that someone having the right vocabulary can zoom in on a field in very little time and write a filter (ad-hoc query) fairly quickly. I think this is a strong point of my application and I want to hold on to it.

I'll send you a private message with some info on how to connect. It'll be easier if I show you...

Dear LeBurt,

Did you figure out a solution? I am in the same boat. Would you mind sharing your soltuion?

I have a fair idea of how I want to store the conditions but haven't got to a point on how to evaulate. I am thinking of accomplishing the whole thing with two tables.

I can elaborate the solution if you are interested.

Thanks,
Nachi

Hey ranchcharm,

No, I sort of let it go a while back and focused on other things. I kept thinking about it though, on and off. I have a feeling I could possibly apply a stack model used to store and evaluate any kind of expression (arithmetic, boolean). I haven't pushed that wagon very far and therefore don't know how well a database could be used to modelize a stack...

Here's an example: http://www.cse.iitk.ac.in/~sbaswana/.../stack-lec.pdf

I'd be glad to hear about your solution, if you have the time.

pretty much away in time, but i am trying to achieve a similar thing as the original poster. my best idea so far is to store the expression in polish form (operand before operands, no brackets needed), it is much easier to parse after retrieval. another option would be to store the expression as a tree, where the operands and the operators are all nodes (with fields for node type, parent id etc.). i think you only need a single database table for that.