We should be very happy that somebody invented the "NoSQL" name. Once things have a name people can start to talk about this things, and the ideas will move faster.
This recent hype about the NoSQL stuff was only possible because there was a name :)
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.
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.
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?
"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."
The centerpiece of relational databases is reliably joining tables. NoSQL databases remove this constraint for scalability and schema flexibility, so how about NoJOIN?
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.
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.
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.
This recent hype about the NoSQL stuff was only possible because there was a name :)