Hacker News Reader

Comment by scott_s | Hacker News Reader

Which is a completely superficial connection with no relationship to the actual semantics.

Very true. I'm tempted to argue that SQL's English-like syntax was a mistake, but only because I think it makes people think you don't really need to learn it. It's frustrating to see people trash something when they don't even properly understand it - a lot of the database-related blog posts I've seen make the front page of HN would be shot down if they were similarly misinformed about a language like Javascript.

I'm not by any means saying that the NoSQL movement as a whole is a fad - there's good motivations behind some of these products - but a lot of people who are just ignorant also seem to have hopped onto the bandwagon.

That was an issue I had with the post: how can "non-relational" be a good thing about CouchDB? If you have relational data, then there's an entire theory (relational algebra) behind ways to interact with it that have clearly defined semantics. I can see that one may decide they don't need that, but I don't see how it's absence can be a good thing. Being non-relational frees CouchDB to provide different kinds of capabilities, but it's those capabilities that are a good thing, not the lack of being relational itself.

Rather, I think the author has confused "relational" with a lot of other properties of relational databased management systems - such as transactions and data integrity guarantees.

You're right that I was lumping transactions and data integrity guarantees in with "relational". I was thinking about normalization, and protecting data integrity in ways that lead to joins and transactions.

You made me think about something. A CoffeeScript like approach to build a saner language that would sit atop SQL would be something definitely worth having. Maybe this could be the start of the "OnSQL" movement. Just my thoughts.

Being able to parameterize table and column names in queries would be a big help.

It could have a sharding aware data definition language and some support for "on-the-fly" data migrations.

Check out Microsoft's LINQ: http://msdn.microsoft.com/en-us/library/bb397906.aspx

Well, SQLAlchemy is designed just for that. In the words of the author:

> Like "power steering" for SQL. Doesn't teach you how to drive!

Reply on news.ycombinator.com