

Awesome new SQL syntax - for developers - simonhamp
http://forr.st/~4LY

======
ary
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.

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

~~~
ddlatham
_\-- Even complex operations could be expressed more simply_

------
rbanffy
Please, drop the "awesome" from the title.

~~~
simonhamp
The awesome stays

~~~
rbanffy
But this is not awesome.

------
andrewcooke
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.

------
dennisgorelik
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.

~~~
ollysb
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?

~~~
dennisgorelik
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.

------
r00fus
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.

------
krakensden
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.

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

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

------
nestlequ1k
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...](http://sequel.rubyforge.org/rdoc/files/doc/querying_rdoc.html)

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

------
dougabug
It's been done, and pretty well: <http://htsql.org/>

~~~
simonhamp
Awesome!

~~~
MikeMakesIt
You really like that word, don't you?

------
apgwoz
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.

------
wiredd
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).

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

------
kenneth_reitz
Has the author never seen an ORM before?

