Stop calling me NoSQL(blog.dhananjaynene.com)
blog.dhananjaynene.com
Stop calling me NoSQL
http://blog.dhananjaynene.com/2009/10/stop-calling-me-nosql/
20 comments
This reminds me of when the term AJAX was introduced. I thought it was a stupid attempt to foist a "cool" name on an already existing term.
Yet it may be coincidental but that seemed to coincide with the time that using an XMLHTTPRequest took off.
Maybe the branding worked?
Yet it may be coincidental but that seemed to coincide with the time that using an XMLHTTPRequest took off.
Maybe the branding worked?
The NoSQL hype happened because people wanted to explore and promote alternatives. The NoSQL name happened since there was a need to provide a moniker to the alternatives. Since this was a hype and movement based on otherwise real need, it is likely to have happened even if the name was something completely different say FreeQL (or whatever other catchy name). The post isn't arguing there shouldn't be a name. All it is attempting to point out is that it should be a meaningful and appropriate name - else what you think (when you hear the name) and what you get (when you actually dig into the details) are very different. The current name actually makes it harder for newer participants to properly grok these storage systems - which wasn't perhaps the goal in the first place.
Yes indeed, I totally agree that there is a feedback. Something starts to be interesting, then people start to talk about this thing and it's comfortable to name it in some way. Then some name will arise and the discussion will move even faster. Eventually the field gets names for every important concept, and so on...
Still there is something "magic" in this process. Once you get a name for one thing, it starts to get much more obvious. For instance think at the "web 2.0" or "Ajax" cases. NoSQL, in the name itself, is the negation of something else, and this allowed to collect a number of different projects under this name.
Still there is something "magic" in this process. Once you get a name for one thing, it starts to get much more obvious. For instance think at the "web 2.0" or "Ajax" cases. NoSQL, in the name itself, is the negation of something else, and this allowed to collect a number of different projects under this name.
[deleted]
it seems like you’re looking for realistically structured data, not data twisted to fit a formula convenient for mathematicians.
The appropriate words here are "logical" and "physical" not "real" and "unreal". A relation is a logical data structure. Hash tables, trees, and graphs are all physical data structures.
Another accurate thing to say is that hash tables, trees and graphs are all "pointer-based databases" and relational databases are "pointer-free databases".
The second one will be confusing to people accustomed to putting pointers into relations (like what rails does) and turning the relational database into an ad-hoc graph database.
The appropriate words here are "logical" and "physical" not "real" and "unreal". A relation is a logical data structure. Hash tables, trees, and graphs are all physical data structures.
Another accurate thing to say is that hash tables, trees and graphs are all "pointer-based databases" and relational databases are "pointer-free databases".
The second one will be confusing to people accustomed to putting pointers into relations (like what rails does) and turning the relational database into an ad-hoc graph database.
Surrogate keys are very common in real-world relational databases. If an order has a CUSTOMER_ID which was generated mechanically, appears in exactly one tuple of the CUSTOMERS relation, and has no other assigned meaning, isn't it just a pointer to that tuple?
What you describe is a pointer, but not a surrogate key.
http://en.wikipedia.org/wiki/Surrogate_key
"For example, table Staff may contain two rows for "John Smith", one row when he was employed between 1990 and 1999, another row when he was employed between 2001 and 2006. The surrogate key is identical (non-unique) in both rows however the primary key will be unique."
http://en.wikipedia.org/wiki/Surrogate_key
"For example, table Staff may contain two rows for "John Smith", one row when he was employed between 1990 and 1999, another row when he was employed between 2001 and 2006. The surrogate key is identical (non-unique) in both rows however the primary key will be unique."
I think "graph database" is probably the best term I've heard so far.
The centerpiece of relational databases is reliably joining tables. NoSQL databases remove this constraint for scalability and schema flexibility, so how about NoJOIN?
I like "post-relational", but NoSQL is catchy, and has stuck. At least we have a shared vocabulary now.
How about this 4-letter acronym: NSQL (Native Storage Query Language)?
I think this might be a misnomer in that NoSQL in the general sense describes a set of technologies acting as value stores rather than a standardized language for accessing said values.
Native storage query language implies using native i.e., non-standardized query language and API. It's an categorical acronym like AJAX.
There's a difference between SQL and RDBMS. One can interact with a relational database using a "non-standardized query language and API." Part of the problem is that people are conflating the language abstraction of SQL with the physical relationship of the data.
I like the name posted by someone in the comments -- NoTable.
So Bigtable would be a NoTable storage system? I think not!
Exactly. Relation != Table. Tables can represent things other than relations.
I could do without the term as well.
It's like calling FreeBSD 'NoNT' or Linux 'NoWindows'. Just because SQL is what people are used to using for persistence doesn't make this a good name for an alternative style.
It's like calling FreeBSD 'NoNT' or Linux 'NoWindows'. Just because SQL is what people are used to using for persistence doesn't make this a good name for an alternative style.
GraphData.
This recent hype about the NoSQL stuff was only possible because there was a name :)