in reply to Parsing text-based queries to SQL queries

Create a mini-language. You will want to put a UI around this anyways, because you don't want to force the user to understand the table layout. (If they understand that, then why aren't they using SQL?) Plus, you don't want to restrict them to just one table, do you? If you're going to provide this kind of solution, then do it right.

They should also be using business names, not the column names. Otherwise, you're going to get the user who keeps asking "Where's my foo column?!?" (This also aids in security by giving the attacker less information.)

If the UI was HTML, I'd create a form that had dropdowns. The first set of dropdowns is the information they want to see. (SELECT * is a security hole.) They'd be able to pick a bunch, including the COUNT(*), SUM(colname), etc. Then, I'd have the restrictions, and this would be three dropdowns. One for the column name, one for the value, and one for the operator. Then, between the triplets, I'd have another dropdown with "AND" and "OR" in it. Parentheses would be added giving the user the ability to group together statements, maybe with another dropdown next to the AND/OR dropdown. At the end, provide the ability to order based on the items they chose to see. If the user chose any grouped SELECT statements, I'd automatically group the rest of the statements for them. No HAVING would be allowed (initially).

That's not that hard, really.


My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re: Parsing text-based queries to SQL queries