Awesome new SQL syntax - for developers | Hacker News Reader

Awesome new SQL syntax - for developers

forr.st

12 pointssimonhamp24 comments

The author seems to be mistaking "simpler" with "terse." There are a lot of people that actually like a certain level of verbosity as it can help with comprehension.

There's no mention of it being "simpler"...

"What I actually want is something that allows me to write less code and still get my beautiful SQL query."

You're suggesting a shorthand for SQL. Forgive me if I assumed you were trying to simplify something you see as too verbose and complex.

-- Even complex operations could be expressed more simply

Please, drop the "awesome" from the title.

The awesome stays

But this is not awesome.

I can't see the comments on that site (maybe adblock is killing them?), so this may be a duplicate, but I would suggest reading Date's "SQL and Relational Theory" and looking at Tutorial D (an alternative to SQL) before implementing this. At the very least it would clarify how you might use sets and where you need to worry about things like ordering if you are going to reproduce SQL faithfully.

The author forgot that in order to be successful in business environment SQL must be readable by advanced business users (with help of developers). "Awesome new SQL syntax" is clearly for developers only and is not not suitable for business users.

I'm aware that sql was originally intended to be used by non technical business users but I've never known a single one that did. Have you had experience with people that do?

Yes I worked with some business people who understand SQL (at least somewhat).

Any business analyst worth its salt understand and can write at least simple SQL (to pull the data from database).

But even if business folks on your current project do not care about understanding SQL,your next project would have such people. So it would be very helpful if SQL version you have experience with is business-friendly.

Not clear if this is a domain specific language that would generate SQL, but when I was working for the big enterprise players they always had a way to abstract SQL running against several DB engines... (one of 'em called it meta-sql).

There was a significant effort to push this, and it was only successful because it was embedded into the dev environment of the enterprise software.

Great idea, but the many different versions of SQL syntax will be a pain to properly implement. I'd suggest staying with a single DB engine, then branching to others.

I sympathize with the effort, but I think this is the wrong approach. SQL is often difficult/annoying to write because you don't do it very often- maybe once a week, maybe once a month, maybe less. The syntax is acceptable, but it's very different from the various languages I work with on a regular basis, and occasionally you forget things.

With this, you have even less muscle memory, since maybe one hobby project you work on will use it, making recall, comprehension, and debugging that much more difficult.

I agree with this except I use SQL day in-day out... so shorter syntax would actually save me time

what do you do, out of curiosity? I often forget that not everyone lives in my little corner of the development universe.

Here's the awesome new SQL syntax that I use: http://sequel.rubyforge.org/

Examples: http://sequel.rubyforge.org/rdoc/files/doc/querying_rdoc.htm...

That's ORM and whole load of other sweetness... This is just SQL syntax... only shorter

It's been done, and pretty well: http://htsql.org/

Awesome!

You really like that word, don't you?

Surprisingly close to something I've been thinking about, and working on a bit in my spare time, for me:

     :table(id=1) => SELECT * FROM table WHERE id = 1

Hadn't thought about mutation, only selecting though.

I like that someone is trying to come up with a better SQL syntax, and agree that many existing OO wrappers (and NoSql query syntaxes) end up making it more difficult to write queries. But this proposal seems to make things a little too brief for my taste (what's the difference between < and > again?).

I wonder if there's more to be gained by developing shorthand for more complex bits of SQL. For example, I've always been annoyed by the group by syntax, which seems redundant since the SQL interpreter should be able to determine which SELECT columns to group by (all columns that aren't aggregate functions).

His version is just too much more harder to read...

Has the author never seen an ORM before?

Reply on news.ycombinator.com