This is absolutely incredible. I described to it the tool I built at www.human.software, explained to it how it works and it generated valid SQL code based on a question I asked in this language I designed and explained to it ad hoc.
It has the ability to learn on the fly and conceptualize based on minimal descriptions of complex systems. You cannot see it below but I even had a conversation about how to pitch the concept and brainstormed a few ideas (very heavily guided by me).

Ionut Georgian Ciobanu
I created a tool that enables users to build english sentences via consecutive dropdowns in order to query a database, given that it has the schema and access to the database. the user can combine verbs such as "all users" or "all orders" to see the list of users or orders, or "the number of users" or "the average order amount" in order to form complex data questions. what other verbs might be helpful?

Ionut Georgian Ciobanu
if the user is non-technical such as a salesperson or marketing person, how can we make it easier for them to query data without having to use the word join?

If the user is non-technical, such as a salesperson or marketing person, it may be helpful to provide a more user-friendly interface for querying the database. Instead of requiring the user to specify which tables to join and the type of join to use, the tool can provide pre-defined options for common queries that the user can select from. For example, the tool could provide options like "Show me all orders," "Find customers in a specific city," or "Sort customers by order amount," and then automatically generate the appropriate query to retrieve the desired data. This can make it easier for non-technical users to query the database without having to understand the technical details of how the tables are joined.

Ionut Georgian Ciobanu
if there are 50 tables in the database there are too many possible pre-made queries to generate. how else can we make it easy for the user to query

If there are many tables in the database, it may not be practical to provide pre-defined options for every possible query. In this case, there are a few other ways to make it easier for the user to query the database:

Provide a search function that allows the user to enter keywords or phrases related to the data they are looking for. The tool can then use natural language processing (NLP) to understand the user's intent and generate the appropriate query.
Use machine learning to predict which tables and fields are most likely to be relevant to the user's query, and automatically suggest them as options in the query builder.
Provide a way for the user to browse the schema and see the structure and contents of the tables in the database. This can help the user understand the data that is available and make it easier to identify which tables and fields to include in the query.
By providing these features, the tool can make it easier for the user to query the database, even if there are many tables and a large amount of data available.

Ionut Georgian Ciobanu
if the verbs the user can build are "list of", "for each", "number of" and the nouns are the tables of the schema, how should the user build the same question as before: Who are the top 10 users by number of orders for each city?"

To build the query "Who are the top 10 users by number of orders for each city?" using the verbs "list of," "for each," and "number of" and the nouns in the schema, the user would need to select the appropriate nouns and verbs from the dropdown menus provided by the tool. The user would first need to select the "users" table as the subject of the query, and then use the "list of" verb to retrieve a list of users.

Next, the user would need to specify the criteria for identifying the top 10 users. This can be done by selecting the "orders" table and using the "number of" verb to count the number of orders for each user. The user can then use the "for each" verb to group the users by city and the "top" option to select the top 10 users in each group.

Finally, the user can specify the fields to include in the results, such as the user's name and city, and the format of the results, such as a table or chart. The tool can then generate the appropriate query and retrieve the results from the database. The user can view the results in the schema browser and analyze the data to answer the question.

Ionut Georgian Ciobanu
wouldn't it make more sense for the user to pick the action first and then the table and field?

It may make more sense for the user to pick the action first and then the table and field, depending on the user's preferences and the design of the tool. Some users may find it easier to think about the actions they want to perform on the data before selecting the specific tables and fields to use. For example, the user may want to "find" the top 10 users by number of orders before specifying which table to use to identify the users and which field to use to count the orders.

In general, the design of the tool should be flexible and allow the user to select the tables and fields in the order that makes the most sense to them. The tool can provide options for selecting the action, the tables and fields, and the criteria for the query, and then use these inputs to generate the appropriate query and retrieve the results from the database. This can help make the tool more user-friendly and allow the user to build the queries they need in the most efficient and intuitive way.

Ionut Georgian Ciobanu
what would the sql query for such a question look like?

The SQL query for the question "Who are the top 10 users by number of orders for each city?" would depend on the specific schema of the database and the details of the query. Here is one possible SQL query that could be used to answer this question:

Copy code
SELECT u.name, u.city, COUNT(o.id) AS num_orders
FROM users u
INNER JOIN orders o ON o.user_id = u.id
GROUP BY u.city
HAVING COUNT(o.id) >= (
SELECT COUNT(o2.id)
FROM orders o2
WHERE o2.user_id = u.id
ORDER BY COUNT(o2.id) DESC
LIMIT 10
)
ORDER BY num_orders DESC