One use case that tends to pop up frequently is “text-to-database”. Similar to text-to-SQL, but with my API I could target any DB regardless of query language. This would require a large amount of work, and I’m not convinced that it’s something that users even want. The strongest feedback I’ve received has been that it would be a convenient method for managers and non-technical to query analytics databases.
Is this a path worth exploring? Are there industries or positions that would kill to be able to query a db with a plain english sentence? Is this something that you would use, or want to implement?
But maybe you're asking the wrong question in your headline. If you could have other people in your organization able to talk to a database in plain English, would you?
This isn't something that most of the HN crowd would want for their own work. There might be a lot of people here who have, say, that upper-level manager who keeps asking for reports for which the HN person has to figure out how to get the data. Handing that manager a tool like this, and letting them run their own queries could get them out of our hair. (It could also be better for the manager, as they run the query, look at the results, and figure out that it wasn't actually the data they were looking for, and so they can iterate the query to get what they're really after.)
One caveat, though: I wouldn't want to hand anyone - even a professional - write access with this kind of a tool.
Ultimately though, I think the usefulness of these tools breaks down for both complex queries and even simple ones when the data model does not have explicit relationships defined.
Trying to map english to formal logic is a fools errand.
From my experience, what keeps non-technical people from writing queries isn't SQL, it's stuff like joins.
At the end of the day, SQL is very expressive for most of these queries, but it's not particularly discoverable and does take some knowledge. Lowering that barrier to entry is a great idea, but otherwise I'm not sure if an analyst can be certain their query will give the same data as somebody who uses slightly different phrasing. SQL gives a lot more precision and I would hate to lose that due to a layer of abstraction.
But English -> SQL (with something like Github Copilot, built on other analysts' queries) would be very interesting although not "get out my wallet and purchase" compelling.
I think this is definitely something that should be looked at, but it's not a product I'm really interested in unless it wows me with it's intelligence. It has to start somewhere, though. I'm probably an outlier in the sense that I think a lot of people would rather talk to their computer than type on a keyboard. I'm just not one of them. I also don't want to work in cubicle hell with everyone speaking to their computer 24/7.
Selling such a thing should not be a problem given the right target. Not only has the customer space for technologies like that changed over time, but you are providing a new twist on the solution.
> “Stripe/Twilio for NLU”, but recent feedback has been that it’s more a “technology”, and less a “product”
That comment doesn't make a ton of sense to me. Are services not valuable? Stripe and Twilio seem like really helpful services and that seems...OK to me?
Personally I get excited when I hear about an ease-of-use wrapper around regex. But for a DB, in place of that regular messy query stuff with the prospect of things like multiple LEFT JOINS? That's a big deal.
And even if it doesn't tick every box it will probably I'd guess it would have its unique applications for a given set of customers.
Like let's say sets of people who would like to prototype to well-enough using their ability to sit around and talk in English all day long, and then hand off to someone else. The average person's energy pool for trying different sentences, even considering some expected failure rate, is so much deeper than the resources available for trying and failing with different SQL statements.
This would also apply to those who are not really working with the data to work with it. Let's say they are selling data-viz tools and want a quick way to make prototypes from the potential customer's sample data. There, boom, product example. I guess.
It sounds really cool. Good luck, hope it works out for you.
Regardless of the details of the language, if I'm going to learn a structured language anyway, I would usually prefer to learn the underlying language, and not an imperfect abstraction. Sometimes, there's good value in the abstraction, but I usually find they get in the way and make it harder to do what I want.