Live data from Hacker News

Show HN: Natural-SQL-7B, a strong text-to-SQL model

github.com

91–100 of 171 posts

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#91

Earlier quoted context omitted.

Honestly I would rather write stuff in code thats inefficient than deal with one more stored procedure. Its like a black box

Just that deeply inside that forest of functions you just wrote is the inner join that the SQL query would do in a couple of lines of code embedded.

more like, when it comes to complex data structures and logic, i will do that outside of sql. I'll do a join with sql no problem, by the time we're doing multiple inner joins I usually prefer to just do multiple sql queries. I don't care about performance that badly.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#92
post #81

One Problem I always see in such apps is that the ai can't see in to the database or into all entries, so queries without stating data EXACTLY as in the database run into issues. example: give me the revenue for all logistics firms but in the database these might not be called "logistics" and may be called "transport" (or anything) maybe there are some counters to this like finding unique values per column or even be…

Usually you include the database schema in the context, usually by showing the CREATE statement for the tables you want to query. I've also found that including comments in the CREATE sql can guide the model somewhat. The best approach is probably to finetune one of these models using curated questions for your database.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#93
post #21

So it looks like it scores 76.5% on SQL-Eval [0], a bit behind GPT-4 at 83% and sqlcoder-15b at 78%. What kind of applications would this be useful for? What can you build with an AI data science intern that's right 75% of the time? As a programmer who always has to look stuff up when I SQL, I could definitely see asking something like this for a first draft of a query but it seems like I'm slightly better off asking…

Imo stuff like this can have applications in a narrower set of problems, where you can also further finetune or simple prompt engineer a model to have a much higher accuracy. I do not think that they can become the bases in which database work is gonna take place in general, but it could be used to automate certain types of tasks that would be too hard/complicated to automate in a classical programmatic way, but not too hard/complicated a real intelligence to be needed to solve.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#94
post #21

So it looks like it scores 76.5% on SQL-Eval [0], a bit behind GPT-4 at 83% and sqlcoder-15b at 78%. What kind of applications would this be useful for? What can you build with an AI data science intern that's right 75% of the time? As a programmer who always has to look stuff up when I SQL, I could definitely see asking something like this for a first draft of a query but it seems like I'm slightly better off asking…

> What kind of applications would this be useful for? What can you build with an AI data science intern that's right 75% of the time?

I have written a bunch of more or less complicated SQL during my career. And I am pretty sure that if I need to write a SQL statement that's anything but select * from table, my output won't work 75% of time.

I may be special case, but typically if I work on a hard problem, it is not a single hard problem but a sh*tload of connected simple problems. If I can get someone to solve the simple problems 75% of the time correctly so that I can spend my time figuring out how those simple problems are to be connected, I'm ore than happy. And that's exactly how I use chatgpt. I have learned not to ask too complex questions from it. But the simple ones, it mostly aces and when it does not , they are easy to spot, as it is not that I could not have solved them myself, I just did not want to spend time for that. Now, if only the chatgpt was not almost as lazy as me to produce long simple stuff, that would be awesome.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#95

Earlier quoted context omitted.

1. If you are a a programmer I think you should learn SQL. It will give you a different perspective on programming that I think is invaluable. (I.e. programming without for loops) 2. Combining and slicing data is a craft, and doing it subtly wrong in one step can lead to fatal errors in the outcome. And most importantly, it can be very difficult to notice. Numbers don't smell. That is why I would be very hesitant to…

What makes you think that SQL doesn't have "for loops"? Ever heard of LATERAL joins/CROSS APPLY? SELECT loop.value, x.squared FROM generate_series(1,5) AS loop(value) CROSS JOIN LATERAL (SELECT loop.value * loop.value AS squared) AS x;

I don't think that the point was that there are no for loops in SQL. I think the point was that almost always using for loops is wrong and super inefficient and there is a much more efficient way to just use joins instead.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#96

Earlier quoted context omitted.

Just that deeply inside that forest of functions you just wrote is the inner join that the SQL query would do in a couple of lines of code embedded.

more like, when it comes to complex data structures and logic, i will do that outside of sql. I'll do a join with sql no problem, by the time we're doing multiple inner joins I usually prefer to just do multiple sql queries. I don't care about performance that badly.

I usually only do one join at a time. But I separate them with CTEs ("WITH"). I can agree that many joins at once can make you grow grey hair.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#97

Earlier quoted context omitted.

1. If you are a a programmer I think you should learn SQL. It will give you a different perspective on programming that I think is invaluable. (I.e. programming without for loops) 2. Combining and slicing data is a craft, and doing it subtly wrong in one step can lead to fatal errors in the outcome. And most importantly, it can be very difficult to notice. Numbers don't smell. That is why I would be very hesitant to…

What makes you think that SQL doesn't have "for loops"? Ever heard of LATERAL joins/CROSS APPLY? SELECT loop.value, x.squared FROM generate_series(1,5) AS loop(value) CROSS JOIN LATERAL (SELECT loop.value * loop.value AS squared) AS x;

LATERAL first available in PostgreSQL 9.3 (2013), but still not available in SQLite.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#98
post #82

Earlier quoted context omitted.

What makes you think that SQL doesn't have "for loops"? Ever heard of LATERAL joins/CROSS APPLY? SELECT loop.value, x.squared FROM generate_series(1,5) AS loop(value) CROSS JOIN LATERAL (SELECT loop.value * loop.value AS squared) AS x;

What is the point of the cross join? This would work as well: SELECT loop.value, loop.value * loop.value FROM generate_series(1,5) AS loop(value)

For this example, nothing. It would be useful where neither of the two SELECT queries is a subset/superset of the other. (Not saying you didn't know that.)

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#99

Earlier quoted context omitted.

What makes you think that SQL doesn't have "for loops"? Ever heard of LATERAL joins/CROSS APPLY? SELECT loop.value, x.squared FROM generate_series(1,5) AS loop(value) CROSS JOIN LATERAL (SELECT loop.value * loop.value AS squared) AS x;

LATERAL first available in PostgreSQL 9.3 (2013), but still not available in SQLite.

SQLite has RECURSIVE, so you can generate a table with all numbers using something like:

WITH RECURSIVE cnt(x) AS ( SELECT 1 UNION ALL SELECT x+1 FROM cnt LIMIT 5 ) SELECT x FROM cnt;

And then do a regular CROSS JOIN on that table.

Re: Show HN: Natural-SQL-7B, a strong text-to-SQL model

#100
post #82

Earlier quoted context omitted.

What is the point of the cross join? This would work as well: SELECT loop.value, loop.value * loop.value FROM generate_series(1,5) AS loop(value)

For this example, nothing. It would be useful where neither of the two SELECT queries is a subset/superset of the other. (Not saying you didn't know that.)

Could you give an example?
Post reply on HN