Live data from Hacker News

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

github.com

161–170 of 171 posts

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

#161

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…

Agreed, it's limited, ugly, and I'd rather use something else. Everytime I have to use it it's cumbersome.

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

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

SQL is like regex, one of those things I will keep unlearning if I'm not using daily.

Also the way each DB supports its own dialer is quite maddening.

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

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

SQL is a programming language! It is just declarative. And most programmers are associating imperative programming language as programming language. [1]

I found while declarative and functional programming languages are not as often used, however learning them made me a better programer.

[1]: https://stackoverflow.com/questions/10925689/functional-prog...

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

#164
post #160
post #104

Earlier quoted context omitted.

Yep. Open source means you can build and modify it. If not, it’s not open source. You know it’s a bad timeline when releasing the equivalent of a binary is considered “open”.

Except people modify "non open source" but "weights available" models all the time. In fact, this very model is such modification (fine tune) of the original base model.

Except it's not really known for all non-open-source licenses are allowed to be modified. I can similarly jailbreak a phone but it's not open source.

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

#165

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.

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

At which point - but not earlier! - you just make your ORM print the queries, fix them manually (or write them from scratch). You then can ditch the ORM, use it as a query builder DSL only, or use escape hatches provided by the ORM to inject raw SQL.

Don't use ORMs as a crutch to get away with not knowing SQL, that's bad. However, saving "a bit" - and with good ORMs, that "bit" is quite large - of time in the beginning is often very valuable. Just have a clear "exit strategy" for when (and in 90% of projects, if) it's needed.

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

#166

Earlier quoted context omitted.

Yeah, we've been working on this problem a good bit and I think text-to-sql is a dead-end for analytical questions. We ( https://www.definite.app/ ) ended up abandoning text-to-sql in favor of answering questions with a semantic layer (which LLM's are far more effective against). https://www.loom.com/share/a0d3c0e273004d7982b2aed24628ef40

So you don’t use AI to generate SQL to retrieve data? As you say on the web site?

We ultimately generate SQL, but the LLM doesn't write SQL, the semantic layer does.

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

#167

Earlier quoted context omitted.

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.

> joins in every database are implemented literally with for loops written in c.

different kind of loops can be different, e.g. 2 nested loop with quadratic time:

for i in t1: for j in t2:

vs sort + merge join with n log n time.

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

#169

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.

> the most valuable and useful language ... Programmers think the most valuable language is a programming language. Therefore, an LLM that can generate quality code in that language should also be extremely valuable. I'd argue that the most valuable language is the natural language of the organization you're writing code for. That language is vague and ambiguous, and encapsulates many hidden assumptions about how tha…

That's a very 2023 comment but I have a feeling it won't hold up. Yes natural language communication is and has been a very undervalued skill in software development. LLMs have made the skill even more valuable, but in the end your solution is being written in one or more languages with additional features that are absent from natural languages and a programmer still needs to understand what they are building, in all of its complexity, in order to build solutions of real value. I don't see that changing for a little while. In the meantime, programmers will become better natural language communicators.

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

#170
I have a use case where there's no DDL, just a description of the tables, with provided data types, and descriptions of all of the columns, in JSON.

I could generate DDL statements, of course. But wondering if this is the best way to hint at the model of the database structure.

Also, how would you go about supplying the very verbose descriptions of all of the data types? Would SQL comments be best? Postgres-style column comments?

Thanks!

Post reply on HN