One of the things that making SQL (Structure Query Language) so popular is that it has become an ANSI standard for accessing data in relational databases. There are many different relational database engines available, yet the majority of them implement the core functionality of the ANSI SQL syntax.
As No-SQL data engines continue to evolve, they generally do not support a language such as SQL. Most have their own proprietary querying syntax often based on objects instead of tables and relationships. That is not to say that you cannot provide query criteria and have it performed on the storage server. What it means is that the filtering is not done using a query language. This can be a plus and a minus at the same time.
Many do not have any querying language enabling ad-hoc capabilities. Some are adding SQL like syntax to their engine for this purpose, but that is not generally the norm. This means that the No-Sql data store is the restricted playground of software developers alone.
Some engines are developing a proprietary syntax for Ad-hoc purposes. Some are creating SQL parsers, some have a proprietary language, others are created by third paries as an add on to popular engines. What this means is that Architects need to be more careful when designing a system using No-Sql data storage so that they can change to another engine. We constantly say that will never happen; but it seems to happen more often that we would like to admit. Moreover, because of the unique capabilities we have embedded in our applications we are less likely to change when it really would serve the business better.
Are the problems with these new engines any bigger than they were with SQL only data engines when it comes to supporting or changing engines? How about changing from an SQL engine to or from an No-Sql engine? Please share your thoughts on this conversation.
Cheers,
Ben