I built QueryTree (http://querytreeapp.com) as a response to this sort of problem. It's a domain specific visual programming language designed for working with tabular data. So people who want to build a custom query on a database can do it just by dragging and dropping the right "tool" onto the "worksheet".
It's a desktop app rather than web, although it is actually built using HTML, canvas and JavaScript.
It can do almost anything SQL can. It can't do "IN" queries yet but I have a plan do that in a way that's consistent with the general drag and drop approach of the app. It doesn't explicitly handle BETWEEN queries but they are easily achieved by using two filter tools one after the other.
I think there are two types of complexity to be dealt with when enabling users to build reports/queries. One is the complexity of the concepts involved, the other is the complexity of communicating what you want to happen to the computer. I built QueryTree because of a belief that many people understood they the concept of a filter or a join, but just didn't like text based programming languages. I replaced the SQL syntax but left everything else in place. If I didn't think my target users were up to understanding the conceptual complexity I would have restricted it a bit more and would probably have ended up with something like IFTTT.com but for data. Mostly, people seem to "get" QueryTree though, especially when they're using it on data that they're familiar with.
It's a desktop app rather than web, although it is actually built using HTML, canvas and JavaScript.
It can do almost anything SQL can. It can't do "IN" queries yet but I have a plan do that in a way that's consistent with the general drag and drop approach of the app. It doesn't explicitly handle BETWEEN queries but they are easily achieved by using two filter tools one after the other.
I think there are two types of complexity to be dealt with when enabling users to build reports/queries. One is the complexity of the concepts involved, the other is the complexity of communicating what you want to happen to the computer. I built QueryTree because of a belief that many people understood they the concept of a filter or a join, but just didn't like text based programming languages. I replaced the SQL syntax but left everything else in place. If I didn't think my target users were up to understanding the conceptual complexity I would have restricted it a bit more and would probably have ended up with something like IFTTT.com but for data. Mostly, people seem to "get" QueryTree though, especially when they're using it on data that they're familiar with.