Live data from Hacker News

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

github.com

131–140 of 171 posts

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

#131

Earlier quoted context omitted.

I’ve been working in this industry professionally for close to 25 years now. By far the most valuable and useful language I have learned is SQL.

I have been working in this industry for 30 years now. SQL is one of the most ugliest programming language I have ever working with. Like Perl, it's write once, hope you never need to read, language. SQL was created in 60s. It has not really kept up with the pace of modern programming language ergonomics. It was made for a single person executing a batch job query pulling data from the database. On the other hand, I…

There are preprocessors like PRQL that help with some (far from all) of the pain points of SQL as a language

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

#132
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…

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…

For those people who would rather use an ORM, its worth mentioning that ORMs write very bad, un-performant SQL under the hood.

They may save you a bit of time initially but when your company gets bigger, the ORMs will become a bottleneck.

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

#133

Earlier quoted context omitted.

I have been working in this industry for 30 years now. SQL is one of the most ugliest programming language I have ever working with. Like Perl, it's write once, hope you never need to read, language. SQL was created in 60s. It has not really kept up with the pace of modern programming language ergonomics. It was made for a single person executing a batch job query pulling data from the database. On the other hand, I…

There are preprocessors like PRQL that help with some (far from all) of the pain points of SQL as a language

Hopefully we get over the fact that we still need to transpile something to the ugly SQL and databases themselves start to speak a better language.

Despite all the hate MongoDb deserves, it solved the problem how application developers can easily get data in and out of a database.

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

#134

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…

For those people who would rather use an ORM, its worth mentioning that ORMs write very bad, un-performant SQL under the hood. They may save you a bit of time initially but when your company gets bigger, the ORMs will become a bottleneck.

"Bad" and "un-performant" are relative terms and as your company gets bigger, you're increasingly more and more likely to have colleagues who write even worse queries than an ORM would.

For example I've encountered queries that are not only slow, but they generate several hundred megabytes of output all of which is sent to the user's web browser where JavaScript selects the relevant two kilobytes of data to show the user.

The worst I've ever seen was a system where every single write to the database would be sent to every single web browser viewing certain webpages. 99.999999% of the writes were completely irrelevant and javascript in the browser would simply disregard them. The server load was immense... and eventually our Sysadmin brought it to someone's attention. Where we found out it was leaking sensitive data.

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

#135

Earlier quoted context omitted.

There are preprocessors like PRQL that help with some (far from all) of the pain points of SQL as a language

Hopefully we get over the fact that we still need to transpile something to the ugly SQL and databases themselves start to speak a better language. Despite all the hate MongoDb deserves, it solved the problem how application developers can easily get data in and out of a database.

There are certainly valid syntatical criticisms you can have of SQL[1] but on the whole SQL is expressive and rather concise while being solid enough to remain the default expression language of choice for fifty years.

1. The order of the phrases, the lack of trailing commas, the fact that an awful organization controls the standards and gatekeeps them to a bizarre extent.

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

#137

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;

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.

I wonder if anyone realizes that selects and joins in every database are implemented literally with for loops written in c.

The reason people use a relational database is because it has loops that are faster, safer, and more efficient than anything you can write.

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

#138
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…

The 25% of SQL that covers everything in 99% of applications is a subset of the 76.5% of SQL that the LLM got right.

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

#139
post #41
post #32

I doubt it's useful for complex queries or databases without proper relation info in the database schemes. So it's limited to rather simple queries for users without SQL knowledge. But I doubt they should have direct access to the database tables.

Usually what you do with these type of LLMs is pass on most if not all of the schema in your query. And you’re right in that the end user wouldn’t have access to the schema, although perhaps via prompt injection they could.

The problem is there are programs where the schemes don't show the necessary links between the programs data tables like foreign keys for instance.

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

#140
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…

Yep, just use GPT-4
Post reply on HN