Unified NoSQL Query Language Launched

splitenz writes "Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format, called UnQL (Unstructured Data Query Language — .PS). It has Microsoft's backing."

Comments

Obligatory xkcd

[Daetrin]

Standards

Wrong link in the summery?

[ggy]

Hrm, if you read TFA you'll notice the part

This version of UnQL has no relation to an identically named unstructured data query language proposed by a University of Pennsylvania researcher over a decade ago, Phillips said.

which funnily enough is linked in the summery.
Maybe you should fix this to point to the actual link in TFA http://wwww.unqlspec.org/ ?

Not standard, unified.

[pedantic bore]

"So, everyone will use this unified query language?"

"Yes, it'll be great. No need to rewrite things when moving from one database to another."

"Sounds great. Portable apps! Hooray!"

"It amazes me that nobody has ever done anything like this before."

"Yes, in hindsight it's blindingly obvious. There should have been a single query language all along."

"A single query language--we could call it `S-QL` or something like that."

"Nah, I heard that there's already something called SQL. People would get them confused."

"Why? They're probably totally different things."

"Yeah, probably. It's better to make up new names than to risk confusion. So, what's it called?"

"Uncle."

"Isn't that what you say when you surrender?"

"Yes, but in this case there's no possibility of confusion."

Re:Can somebody explain NoSQLers to me?

[chriswaco]

Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.

Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.

Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records. Because of their rigid structure, they do not version well because copying records to older versions of the schema loses data - if the column doesn't exist there's no place to put the data (imagine if application versions 1 and 2 have to read and write to the same database).

Relational databases have their place and I completely agree that transactions are vital to data integrity, but the fixed column data model is way too limited to store all of the kinds of data used in the real world.

Re:Can somebody explain NoSQLers to me?

[Anonymous Coward]

Have you ever used a relational database?

Every NoSQL approach, be it document-oriented, key-value storage, or the various hybrid approaches, can be very easily implemented using relational techniques. In fact, they are all just subsets of the relational model. Key-value storage is merely a two-column table, for instance.

Basically every decent relational database system today allows you to easily partition your data in almost any way possible. It's trivial to store or replicate a single table's data cross hundreds, thousands, or even tens of thousands of storage and processing nodes.

Relational databases work very well for storing hierarchical data, as well. Recursive common table expressions make it extremely easy to work with such data.

There's just no reason to use a NoSQL database. Relational databases can do everything a NoSQL database can, and then a fuck of a lot more.

Re:Can somebody explain NoSQLers to me?

[Anonymous Coward]

Try to read CJ Date work on relational theory and relational databases. Every single thing you say is wrong, I'm sorry to say that. Relational databases are not about "fixed column data models". It's not an ACID Excel. It's not about tables. It's about sets and how sets relates to it's members and to other sets. This includes hierarchical models, which are easily expressed in a RDBMS.

Those who doesn't understand relational databases are bound to reinvent it, poorly.

What a major f* fail in citations

[luis_a_espinal]

What a fail. Notice the second link in the quote below:

splitenz writes:

"Hoping to unify the growing but disparate market of NoSQL databases, the creators behind CouchDB and SQLite have introduced a new query language for the format, called UnQL (Unstructured Data Query Language — .PS). It has Microsoft's backing."

Then, FTA (right at the bottom of it):

This version of UnQL has no relation to an identically named unstructured data query language proposed by a University of Pennsylvania researcher over a decade ago, Phillips said.

I know it's slashdot, but c'mon. Just looking at the linked postscript file shows you a major WTF discrepancy. First the paper is from 2000, and then that paper's query language is based on algebras that do not resemble Codd's relational algebra at all. And that runs counter to this, also FTFA:

Like SQL, UnQL was built on the foundation of relational algebra, Phillips said.

The news are great. The coverage blows. It would pay to read the stuff that is being submitted as a story... just sayin...

Re:Can somebody explain NoSQLers to me?

[Joey Vegetables]

Developer and former DBA here. Yes, the relational model is more than capable of expressing hierarchical data. However, the SQL language, at least the subset common to most popular RDBMSs, doesn't grok hiearchical data very well. And that leads to a point Codd, Date and others make pretty much every day of their lives: Relational =! SQL. The relational model has elegance and power that can't be expressed in SQL, at least not easily. But many of those confronted with the shortcomings of SQL falsely assume these to be shortcomings of the relational model as well, which in most cases they are not.

Re:Can somebody explain NoSQLers to me?

[gfody]

If you're persisting the objects from your oo app then you're already doing it wrong. ORM libraries, etc. are just further down the hole. If you can't be bothered to think about what information describes your objects then you don't have persistence, you have persistent cache which is all hibernate is supposed to be. If your app is boxed software or a game or something then that's probably good enough. But if your app is online and expected to scale and evolve over time then choosing to persist objects rather than information is shooting yourself in the foot.

I'm curious, what happens to all the objects in your object store when the application changes?

Re:Can somebody explain NoSQLers to me?

[AuMatar]

And then you ha0ve a use case change. Or need to interface with an app written in another language. Or find that *shock* while a certain object is very effective for holding some information, it's a horrible way of storing for query. An object should be designed for the use case at hand, the database should be designed for efficient retrieval for that and future use cases. The two are damned near never the same. Persistence frameworks are a mistake.