Hacker News new | past | comments | ask | show | jobs | submit login

The title is correct, the article confused and somewhat pointless. NoSQL is about the systems, not the query language, but it's not about RDBMS minus atomicity and consistency, it's about saying "this not SQL, don't compare it to RDBMS that you are used to querying with SQL".

Anyone talking about how you can implement SQL on top of NoSQL systems is missing the point. KV and Document stores are a different way of storing data.

SQL: express what you want to happen using relational notation, and it will magically happen. There are no real-world performance issues.

NoSQL: certain operations are fast, other operations are slow. This fact is reflected in the API.




The article isn't confused - he's using the SQL in the same way you are (in your first paragraph, anyway) - he's referring to RDBMS's. His point is that that many of the performance benefits of a KV/documentstore based db can be achieved in an RDBMS without throwing away time-tested ideas like ACID guarantees.

I was confused by your post, however. You initially state that NoSQL is about the system/approach to storing data (and not the query language) but then proceed to contrast querying APIs.


    > SQL: express what you want to happen using relational notation,
    > and it will magically happen. There are no real-world
    > performance issues.
I don't think that's true: Consider the

CREATE INDEX

statement - it's part of the API and it is intended for improving performance. True, a RDBMS will execute a query even if the programmer didn't issue CREATE INDEX before - but this more reflects the rigid separation ('data independence') of the logical and physical data model than a lack of control (API exposure) over performance details.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: