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.
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.
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.
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 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).
25 comments
[ 3.8 ms ] story [ 47.7 ms ] threadAny 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.
Examples: http://sequel.rubyforge.org/rdoc/files/doc/querying_rdoc.htm...
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.
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.
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 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).