Not sure whether not only sql clarifies or confuses. I would imagine that name to be appropriate in the contexts where a combination of NoSQL databases along with some RDBMS gets used. It may sound less abrasive, but I would’ve a preferred a name which illuminates or enlightens.

Sam

> dominant tori example …
Great counterexample you give. I missed this point. And I agree you might be right that the nosql might have to pay back later (as the technical dept discussion in source code…).

But I think it is already too late. The term nosql is sinking into every search engine and twitter database deeper and deeper for far more then half a year. Even I am gathering all nosql material under http://nosql-databases.org to give something back to the community.

So if the nosql community would find a clear name (which is also good for marketing) I would be happy about this new name. But I don’t see any way how this could ever happen. It’s always an evolutionary shift coming from within.

Regards

It is important to distinguish between shortcomings of a language (or schema, grammar, tool, appliance, process, method) and the individual. Take the very example you mentioned, EAV. I submit to you that from the point of view of schema definition, the EAV is the perfect example of a simple star schema with an entity relation, a attribute relation and an entity-attribute-value relation. Again, strictly from a modelling perspective, the cardinality of the EAV relation will be large and the cardinality of the attribute relationship is likely to be large as well. Either on an SMP database or on an MPP database, you end up with a smaller representation if you were to use a star-schema.

At a different level of looking at it, EAV in an un-normalized representation is still a relational representation.

So, along comes the requirement/criticism that all values need not have the same general data “type”. Some are numbers, some are boolean and some are strings. Without loss of generality, these can all be represented as strings and again, without any loss of generality this can be represented with multiple columns of different datatypes, number (with suitable p, s), boolean or CHAR(1) and VARCHAR(N).

The argument you propose for the EAV is the perfect example of a restricted case of my claim regarding NoSQL: you propose with EAV, a table with two key columns (or a composite key with two columns) and a string field (VARCHAR(N)) because it so happens that the data is potentially a string. Recently I did encounter one person who stored medical data in a EAV style schema and one of the cases for the value was an image (xray, ecg, mri) and therefore they used a LOB.

So, I’m not so sure that the view that all data (when modeled appropriately) is relational.

But, that does not mean that all data must be modeled in a relational database. There may be limitations in relational technology as it stands today that make it infeasible.

To date, I know of only one class of such problems that are not well solvable with current relational databases. I still have not heard a specific example of something that justifies NoSQL as a “requirement” or for that matter even a “simplification”.

If you have some examples where NoSQL (or by extension MR/Hadoop) are the only way to solve a problem due to limitations in relational databases, I’d love to know more.

Thx,

-amrith

all data is in fact relational

Looking at data in an abstract sense, relational is not the attribute of the data but the way it is modeled. All data ‘could’ be modeled as relational. However not everyone is comfortable doing so under all the circumstances. While relational may continue to be a valid way to model the data it is not necessarily the most convenient – eg. compromise solutions such as Entity Attribute Value Model

NoSQL (call it what you will) is in some respects a 1 column table where the single column is a xLOB

Coming from a relational background thats what it will seem like – since relational has this catch all exception handling construct called a blob (its a place to dump all data that is too inconvenient to model in a relational form). But again I would submit thats just looking at the solution from a very polarised (relational) set of lenses.

Cheers.

Let me draw a political analogy here. Lets assume conservatives (tories) have ruled for ages and become so dominant that everyone else has been marginalised. Some folks get together and combine all other parties and create a new party not_a_tory. The said group now includes liberals, labour, communists.

While it provides a platform for everyone else to group around called not_a_tory, the fact is such a platform has an exceptionally poor identity since its chosen to define itself as what it is not. Everyone who now wishes to join this movement may think it only takes 10 seconds to grok what it is all about soon realises – the entire ‘grokking cost’ has been deferred. Theres a lot higher cost to be paid later in return for temporary platform. Soon enough people start wondering whether the greens should be a part of not_a_tory – since they are quite accurately not a tory.

Soon enough the party grows maybe wins a few seats and then all hell breaks loose since the internal inconsistencies play themselves out. The greens start wanting to join it while imposing the green agenda of environmentalism as well which others want to keep out, while the liberals and communists launch an internal power battle which eventually results in the disintegration of this platform. No amount of forcing attraction to concepts will be helpful in such a situation since the concepts themselves will confuse each other.

If instead such a platform were to identify itself based on what it stood for (a coalition) which essentially is a loose federation of specific parties, then people can easily identify with or away from the coalition and work with the coalition and the constituent parties appropriately. The coalition has an identity independent of the constituent parties clearly defined by what it is for (not what it is against). Thats the way to have a healthy democracy and more importantly a non-confused electorate.

On a separate note investment is a subjective decision based on preferences and priorities. However because I may choose to invest in exercise ‘x’ doesn’t imply that an independent exercise ‘y’ is not worth investing in.

On yet another note – here was another interesting (tongue in cheek) tweet today I saw – “Do filesystems qualify as NoSQL databases? key/value, scalable, distributable, schemaless, good query tools, hierarchical; got it all!” That shows the confusion we are heading towards.

Cheers.

This is a diversion from your serious blog but …

Last week I organized a meet for DBMS/IM folks in Boston and someone in the audience asked about NoSQL, the future etc., The answer was this: “NoSQL movement is like the Ron Paul movement—they are unhappy, don’t like what they have, and have little to offer”.

It is a point of view, not universally accepted (but personally I think it is fairly accurate). I’m still of the mind set that Dr. Codd was in fact correct and with reasonable data analysis, all data is in fact relational. I think that is the case not so much because of the nature of data itself but because it is a reflection of the way we think: through linkages and relationships.

So, to me, NoSQL (call it what you will) is in some respects a 1 column table where the single column is a xLOB and you move the schema into the processing layer.

Toodles!

-amrith

To me we should keep the name and make clear that #nosql is just a symbolic link to something very useful. Then we force attraction to concepts. I for myself will invest in this direction.

Regards

Thanks for the many suggestions. Rather than responding to every suggestion, I think it is best for other readers of this post to reflect on all of these suggestions to more comprehensively grok/discuss the characteristics of this database storage style. Keep the suggestions coming.

Why isn’t it called File Persistence?

- FreeQL (“Freequel” has a nice ring to it )
- NaturalQL

That still leaves the question why you would call a persistence mechanism a query language, but hey, who cares about details?

Hmm. I guess it would make better sense to call it NoRDBMS!

1. SQLess
2. Hybrid Data Storage

But 10-14 years later, Javascript became a scripting platform to Java,

Should we wait for another 10 year ?

That would’ve been all right if the movement was focused on avoiding SQL as a primary intent. But thats hardly the situation – is it ? While I am not sure that it is being used to describe the movement and not the data storage style, that really is besides the point – imo, the moniker simply doesn’t do justice to its intent. Not even remotely.