Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Unified NoSQL Query Language Launched

timothy posted more than 3 years ago | from the ontogeny-recapitulates-phylogeny dept.

Databases 194

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."

cancel ×

194 comments

Sorry! There are no comments related to the filter you selected.

Obligatory xkcd (3, Funny)

Daetrin (576516) | more than 3 years ago | (#36931988)

Standards [xkcd.com]

Re:Obligatory xkcd (1)

Pieroxy (222434) | more than 3 years ago | (#36932044)

More than standards: www.arnnet.com. I will never understand how greed can get someone to serve an ad to some random user instead of the article the user requested in the first place.

If I come to view an article and I don't, I deem the website broken and I leave. I will NEVER again click on a "skip this ad" button. This is just going way too far. If they don't want my eyeballs on their content, that's perfectly fine with me. But they won't have my eyeballs on their crappy advertisements either.

Re:Obligatory xkcd (0)

Anonymous Coward | more than 3 years ago | (#36932076)

A page with a "skip this ad" button is going "way too far"?

Relax, hippy.

Re:Obligatory xkcd (1)

webmistressrachel (903577) | more than 3 years ago | (#36932256)

Yes, some of use still do connect over POTS modems, GSM, crappy 3G and unreliable Belkin54g routers.

Relax, trendy!

Re:More than advertising (2)

b4dc0d3r (1268512) | more than 3 years ago | (#36933142)

I have the opposite problem. If a website doesn't work with NoScript enabled, I deem it broken and never return. I don't have AdBlock, they can show me ads, but not like what you're describing.

I saw an article when I clicked.

Here's the idea. It's my computer, my processor, and if a website wants me to run something they need to ask permission first.

Can somebody explain NoSQLers to me? (1)

Anonymous Coward | more than 3 years ago | (#36932150)

I just don't get NoSQLers at all. Can somebody explain them to me?

So they have trouble scaling systems using existing relational databases because they don't know about indexes, or data partitioning, or how to set up proper hardware configurations for database servers. (Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)

Their solution to this problem is to avoid relational databases completely, instead opting to use so-called "NoSQL" databases that don't offer ACIDity, or basically every other useful feature of relational databases. Then again, many of these NoSQLers don't even seem to know what transactions or referential integrity are in the first place, so maybe they don't even realize what they're missing.

When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints. It doesn't work, and may in fact cause more problems than it actually prevents. Now they mistakenly think that their data has better integrity, when it reality it doesn't.

Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?), they decide to contort it into a query language.

Eventually, their custom-brewed query language ends up evolving into something that's very remarkably like SQL. But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy, which strongly states that SQL is a horrible thing and should forever be avoided. (But when confronted with this similarity, they'll backpedal and claim that the "No" in "NoSQL" means "not only", contradicting the "NoSQL means no SQL ever!" claims they'd made the week before.)

In the end, they've spent a lot of time and effort creating a "database" system that doesn't adhere to the ACID principles in any sensible way, that uses a mangled JavaScript-inspired dialect of SQL, that loses data constantly, that doesn't perform any better than existing relational databases, that doesn't have the maturity of existing relational databases, and that doesn't have the rich set of development and administration tools of existing relational databases.

So after all of this time, effort and pain, what have they truly gained? They're worse off than when they started! Instead of spending a few days to a week to learn how to properly use a relational database, they've spent years upon years trying to do a very poor reimplementation of it. Why? Why do they do this?

Re:Can somebody explain NoSQLers to me? (3, Insightful)

chriswaco (37809) | more than 3 years ago | (#36932296)

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? (5, Insightful)

Anonymous Coward | more than 3 years ago | (#36932344)

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? (0)

Anonymous Coward | more than 3 years ago | (#36932850)

It's sad you're being marked Troll for this post. Nothing about what he said merit being flagged troll, retards.

Re:Can somebody explain NoSQLers to me? (0)

Anonymous Coward | more than 3 years ago | (#36932876)

NoSQL advocates consider the truth to be "trolling", since for some reason it always contradicts what they're saying.

Re:Can somebody explain NoSQLers to me? (0)

spectro (80839) | more than 3 years ago | (#36933112)

Have you ever used a relational database as the datastore for a big object oriented application?

If you do, you will find most of the complexity in your application will lie in all the hacks used to make your domain model work with a relational database.

You can see this working with fluent nhibernate: create a complex object model and then look at how the automapper bends over backwards to generate a relational database schema matching it (and don't show that schema to your DBA or he might get a heart attack)

I think one of NoSQL aims is to solve this issue by replacing the relational database with a datastore that handles objects straight without hacky schemas or ORM libraries.

Re:Can somebody explain NoSQLers to me? (4, Informative)

Anonymous Coward | more than 3 years ago | (#36932530)

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.

Re:Can somebody explain NoSQLers to me? (5, Informative)

Joey Vegetables (686525) | more than 3 years ago | (#36932688)

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.

What about recursive closure? (0)

Anonymous Coward | more than 3 years ago | (#36933144)

Is that even defined in the "standard" relational algebra?

Not quite true (0)

Anonymous Coward | more than 3 years ago | (#36933218)

"Relational databases" (I'll assume you mean RDBMSs here) are not about sets, they're about rows. The difference is that duplicates are permitted unless you explicitly forbid them -- this has various consequences. In relational algebra there is no concept of a "duplicate row".

Re:Can somebody explain NoSQLers to me? (2, Insightful)

luis_a_espinal (1810296) | more than 3 years ago | (#36932486)

I just don't get NoSQLers at all. Can somebody explain them to me? So they have trouble scaling systems using existing relational databases because they don't know about indexes, or data partitioning, or how to set up proper hardware configurations for database servers. (Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)

Generalizations + lies + attempt to ridicule without facts in hand

Their solution to this problem is to avoid relational databases completely, instead opting to use so-called "NoSQL" databases that don't offer ACIDity, or basically every other useful feature of relational databases.

Apparently obvious to the fact that in many non-trivial business cases, you don't need full ACIDity and an eventually consistency model is more appropriate.

Then again, many of these NoSQLers don't even seem to know what transactions or referential integrity are in the first place, so maybe they don't even realize what they're missing.

Generalizations and unsubstantiated blanket statements about a group of software engineers for the mere sake of ridicule (this in contradiction to the first question that is dishonestly presented as a genuine question.)

When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.

Generalization, speculation.

It doesn't work, and may in fact cause more problems than it actually prevents.

Generalizations + hand waving (surprisingly, this didn't contain an instance to a "think of the children" fallacy)

Now they mistakenly think that their data has better integrity, when it reality it doesn't.

Generalization based on a claim that AFAIK has never been made (a poor man's attempt at a strawman.)

Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)

More generalizations as an attempt to ridicule or even insult (no actual, scientific and honest interest to understand the issue at hand.)

they decide to contort it into a query language.

You do have a point, ergo the need for a querying language, which pretty much the topic of TFA.

Eventually, their custom-brewed query language ends up evolving into something that's very remarkably like SQL.

That is a possibility, your point?

But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy

As it has been made apparent in the shitload of literature, interviews and presentations out there (fucking google it?), it has been acknowledge that NoSQL is a misnomer, as the intention was never to move out of SQL, but to provide alternative/competing data representations to the relational model (which provides a very good formal symbolic representation of a certain ubiquitous but not universal class of data.)

which strongly states that SQL is a horrible thing and should forever be avoided.

Says who? Cite references to this effect.

(But when confronted with this similarity, they'll backpedal and claim that the "No" in "NoSQL" means "not only", contradicting the "NoSQL means no SQL ever!" claims they'd made the week before.)

Red herring, strawman. I short, generalizing stupidity.

In the end, they've spent a lot of time and effort creating a "database" system that doesn't adhere to the ACID principles in any sensible way

Because full ACIDity is not desirable in certain classes of problems. Where have you been all this time?

that uses a mangled JavaScript-inspired dialect of SQL

You are taking a random example (MongoDB) based on a very simplistic view to build a blatant generalization easily disproved by facts. Thanks for trying.

that loses data constantly, that doesn't perform any better than existing relational databases, that doesn't have the maturity of existing relational databases, and that doesn't have the rich set of development and administration tools of existing relational databases.

Doesn't perform better? Gee, I wonder how Google, FB and Linkedin operate then. You do have a point regarding maturity and lack of admin tools. But that's what you get when you start at the beginning, and you always start at the beginning. You'd never move out of that point if you were to listen to ever half-educated moron that complains about lack of maturity (no fucking shit Cp. Obvious.) Hell, we wouldn't even had RDMS systems and we would still storing data in flat files being read by COBOL programs if everyone would listen to the likes of you.

You might think you are a mature technology advocate, but in essence you are just acting like a clueless Luddite. Some of the statements you made strongly suggest you are not even that knowledgeable of database theory at all either.

So after all of this time, effort and pain, what have they truly gained? They're worse off than when they started! Instead of spending a few days to a week to learn how to properly use a relational database, they've spent years upon years trying to do a very poor reimplementation of it. Why? Why do they do this?

There is a point to be made that a lot of NoSQL adopters jump into the wagon for cases where a RDBMs would do just find. But there is also a large class of problems where a non-RDBMs system actually would perform better. Relaxation of transaction atomicity/temporal consistency, a different data model, say Document-oriented, property-oriented (on top of a key-value store), multi-column, many of these arising from the mundane (say, in health care systems) to fringe (biomolecular work, geographic data, information extraction, etc.)

But then again, if you had been really intelligent and honestly interested, you would have found this already on your own. Naturally, every one of us would question "why, why do I need this?" upon seeing a new technology. Unfortunately, there is a class of people that for reasons unknown work in software and engineering that don't seem to be capable of doing their own objective investigative work. It baffles the mind.

So, in summary, dude, from your post, you obviously made up your mind already on the subject despite the plenty of literature out there that explains the pros and cons of both NoSQL (or more precisely non-relational stores) and RDBMs and where/how you use each?

So why asking such a rhetorical question then?

There is not an ounce of genuine interest to know the reason why, so why ask the question? Worse yet, why ask the question when the opinion is apparent and the intention, the uncontrollable basal need to ridicule and generalize is clear? From a psychological point of view, I find that deeply disturbing.

Re:Can somebody explain NoSQLers to me? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#36932592)

Try that again, but without so much ad hominem, and without using "generalization" as your only argument against what was said.

It's hard to take you, and other NoSQL advocates, seriously when you don't present sound arguments. The comment you replied to provided us with all of the facts, in a coherent and intelligent manner. You, on the other hand, just threw out one insult and pathetic argument after another.

Re:Can somebody explain NoSQLers to me? (1)

luis_a_espinal (1810296) | more than 3 years ago | (#36932934)

Try that again, but without so much ad hominem, and without using "generalization" as your only argument against what was said.

It's hard to take you, and other NoSQL advocates, seriously when you don't present sound arguments.

Ad hominems. How do pot-kettle. Instead of telling me that I'm ad hominem'ing you, tell me exactly which of the accusations I made (generalizations and ridiculing) is not true. Then we talk.

Also, I'm not a NoSQL advocate at all. I'm a whatever-works advocate. For the majority of cases, for the general case, a relational database system works just fine. For a certain class of problems, it doesn't. Use the tool that is appropriate for the task.

But then again, you are free to generalize me as a NoSQL advocate if that helps you build your argument (given that generalization seems to be your forte.)

The comment you replied to provided us with all of the facts, in a coherent and intelligent manner. You, on the other hand, just threw out one insult and pathetic argument after another.

O really? If that's your understanding of presenting facts in an intelligent, coherent manner, you need to get psychiatric help. Allow me to quote that wonderful piece of intellectual work you are referring to as my last, parting shot. Feel free to stay and belabor on it as you see fit:

1. Attempt to insult via generalizations:

Then they realize that they need some way to query this data. Since most of them only seem to know JavaScript (maybe they were all web designers who pretend to be programmers?)

2. Attempt to a counter-argument by strawman (by referring to a false position NoSQL advocates have ever made):

But of course it isn't SQL! That would be incompatible with their "NoSQL" philosophy

3. Attempt to trivialize by taking a dumb thing to do and painting it as if that's what serious NoSQL advocates do in real life:

(Keep in mind that the system they're "scaling" is a blog getting 50 hits per day.)

4. Attempt to create a refutation via ridicule without substantiating data or citations to the fact:

When they find out that their NoSQL database has corrupted or lost data, they start trying to hack together application-level support for stuff like transactions and constraints.

5. Attempt to negatively compare apples and oranges without specifying a particular context, without showing numbers and while ignoring the fact that many well-published companies (Google, FB, Twitter, LinkedIn) to name a few have use non-relational stores to improve their performance numbers.

that doesn't perform any better than existing relational databases,

6. Attempt to take a few edge case (MongoDB and CouchDB) while maliciously ignoring all the other non-relational stores out there that use more familiar querying languages based on SQL (GAE's data store and GQL, Amazon BigTable restricted SQL, Oracle BerkeleyDB and its restricted SQL capabilities, all other NoSQL stores out there that you can query with XQuery.)

that uses a mangled JavaScript-inspired dialect of SQL

And this last goes to the heart of the matter. You criticize all of the NoSQL stores because a few use a JSON-based query language (which is natural if you store and query things in JSON or BSON format). And the meat of this article is about providing a unifying querying language that is based or related on Codd's relational algebra.

So pretty much you bitch about the problem... in a discussion about a solution to that problem... and where the solution closely resembles at a very mathematical level to the thing you feel more comfortable with (SQL.)

Here is a crowbar. Please use it to get your head out of your ass.

Re:Can somebody explain NoSQLers to me? (1)

The MESMERIC (766636) | more than 3 years ago | (#36932680)

UnReaL !!
GodLike !!
MASSACRE !!!

Multi Kill !!
Mega Kill !!
Ultra Kill!!

M M M MONSTER KILL !!!!

Re:Can somebody explain NoSQLers to me? (2, Funny)

Anonymous Coward | more than 3 years ago | (#36933158)

Mr Breivik, is that you?

Re:Can somebody explain NoSQLers to me? (1)

cjcela (1539859) | more than 3 years ago | (#36932794)

I do not understand why instead of answering the well stated questions of the parent post, people votes it down it. He/She has several good points. And it is also true that a lot of the people who talks about NoSQL has never done serious work, studied, or understand relational databases. Also, I am noticing a lot of fellows commenting here confuse the concept of a relational database with SQL - they are not the same thing, SQL is just one of the possible languages one can use to work with RDBs.

Re:Obligatory xkcd (0)

Anonymous Coward | more than 3 years ago | (#36932278)

Best xkcd ever!

Re:Obligatory xkcd (0)

Anonymous Coward | more than 3 years ago | (#36932890)

Speaking of xkcd and SQL... This one is a classic (in case you live under a rock and never saw it)
http://xkcd.com/327/

Microsoft's backing? (-1)

Anonymous Coward | more than 3 years ago | (#36931990)

so much for UnQL.

Re:Microsoft's backing? (2)

WrongSizeGlass (838941) | more than 3 years ago | (#36932914)

so much for UnQL.

Microsoft likes this? Is that why UnQL is pronounced uncool?

Unstructured [...] Microsoft backing (0)

Noughmad (1044096) | more than 3 years ago | (#36932000)

This is expected, did MS write anything well-structured in their history?

Re:Unstructured [...] Microsoft backing (1)

Pieroxy (222434) | more than 3 years ago | (#36932062)

This is expected, did MS write anything well-structured in their history?

I'm fairly sure their legal dept. is well-structured. I could be wrong though.

Microsoft Legal Dept. (1)

bobbuck (675253) | more than 3 years ago | (#36932202)

I don't know how good they are. They tried to sue me but the court couldn't access the complaint without agreeing to a 30 page EULA.

Holy fuck, they've reinvented SQL! (1)

Anonymous Coward | more than 3 years ago | (#36932004)

Oh my gosh, they've managed to reinvent SQL, but with a shitter JSON-based syntax.

Ah the cycle continues (1)

discord5 (798235) | more than 3 years ago | (#36932018)

Unified NoSQL Query Language

You mean, like a No Structured Query Language Query Language?

UnQL - Unstructured Data Query Language

Oh... Wellp, I'm always going to read this as "uncle". Then again I always read SQL as "squeel", so I'm far from the authority on abbreviations, but strangely enough I always read NoSQL as "No Squirrel".

It has Microsoft's backing.

Queue flamewar in 5.. 4.. 3..

Re:Ah the cycle continues (1)

ianare (1132971) | more than 3 years ago | (#36932074)

FTFA :

UnQL, pronounced "Uncle"

Hmm, I have a better name (0)

Anonymous Coward | more than 3 years ago | (#36933016)

Nearly Unstructured Map Space Query Language (NUMSQL, pronounced "numb-skull")

What flamewar? (1)

Migala77 (1179151) | more than 3 years ago | (#36932082)

No flamewar necessary. Oracle is the new evil overlord.
Having backing from Microsoft just makes it irrelevant.

Re:Ah the cycle continues (1)

hedwards (940851) | more than 3 years ago | (#36932864)

SQL isn't an acronym, it's just a series of three letters that get pronounced as such. It's not fundamentally any different than FBI, FDA or DSHS in that respect.

Re:Ah the cycle continues (1)

Anonymous Coward | more than 3 years ago | (#36933244)

Structured Query Language.

/perhaps I missed the 'whooosh'.

Re:Ah the cycle continues (1)

osu-neko (2604) | more than 3 years ago | (#36933686)

SQL isn't an acronym, it's just a series of three letters that get pronounced as such.

Depends on where you are, apparently. I was told by someone once that you could tell which coast someone was from depending on whether they pronounced that "ess que ell" or "sequel", but I don't remember which coast was which, or whether that's still true today (or for that matter, whether it ever really way). I hear it both ways in the midwest, in any case. I pronounce is "ess que ell" myself, but I do recognize that your statement is false in general, despite being true for me.

flamewar, indeed (0)

Anonymous Coward | more than 3 years ago | (#36933622)

Queue flamewar in 5.. 4.. 3..

It's cue, you ignorant fuck.

common term (1)

jeremypv (455256) | more than 3 years ago | (#36932048)

SQL - Sequel
UnQL - Un-Cool

Re:common term (0)

Seumas (6865) | more than 3 years ago | (#36932080)

Commonly incorrect term, you mean.

Re:common term (0)

Anonymous Coward | more than 3 years ago | (#36932104)

UnQL - Uncle, Ankle, Unglue

Re:common term (0)

Anne Thwacks (531696) | more than 3 years ago | (#36932404)

Anyone who is not an MS Shill knows that Sequel was the (IBM) predecessor to SQL, and is not the same as SQL at all. MS shills, by definition, know nothing.

Now get of my lawn.

Re:common term (1)

FreakyGreenLeaky (1536953) | more than 3 years ago | (#36932502)

Now get ofF _my_ lawn!

Let me get this straight (0)

Anonymous Coward | more than 3 years ago | (#36932110)

They're putting together a structured language for querying this unstructured DB crap.

Microsoft is backing an open-source initiative.

Wake me up when Im sober. No I did not read TFA

What? (0)

Anonymous Coward | more than 3 years ago | (#36932122)

I'm sorry... what? TFA has no content and UnQL [acm.org] is from 2000.

Re:What? (1)

sammyF70 (1154563) | more than 3 years ago | (#36932166)

from TFA : "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."

Trivially (2)

VincenzoRomano (881055) | more than 3 years ago | (#36932136)

It has Microsoft's backing."

It won't work.

Re:Trivially (1)

KiloByte (825081) | more than 3 years ago | (#36932186)

Yet your boss will read things on glossy paper and make you use it.

Re:Trivially (0)

Anonymous Coward | more than 3 years ago | (#36932222)

I'm my boss, and glossy paper, colorful schemas and PowerPoint(tm) presentations are never enough.
You could change my mind by showing me real benefits in terms of development effectiveness and runtime performances ...
Both things are usually out of Micro$oft scopes.

Re:Trivially (1)

KiloByte (825081) | more than 3 years ago | (#36932394)

Unless you're selling an end-user product, which hardly ever happens in IT, you rarely get to choose what you need to interface with.

no examples? seriously? (2)

MichaelKristopeit352 (1968160) | more than 3 years ago | (#36932142)

a text based article about a new text language without a single example of the new language or any attempt to justify its necessity?

slashdot = stagnated

About time (1)

ianare (1132971) | more than 3 years ago | (#36932146)

Hopefully the other DBs get on board with this, especially MongoDB and Cassandra, which at the moment seem to be the most advanced and stable. At least that in the future it would be much easier to test and/or migrate from one NoSQL DB to another. Easier options are a good thing !

For example, we've been looking into using a NoSQL solution for storing certain elements of our web application. Unfortunately, it's hard to test the advantages and disadvantages of each without rewriting the connection and logic code. Writing some sort of custom wrapper just for basic testing seems like a huge waste of time and a likely source of errors.

Just in time! (2)

Angst Badger (8636) | more than 3 years ago | (#36932152)

There was way too much experimentation and innovation going on in the NoSQL world. This should help kill it.

Re:Just in time! (0)

Anonymous Coward | more than 3 years ago | (#36932238)

What sort of "innovation" are they responsible for? The only "innovation" I've seen from the NoSQL community is in their ability to rapidly hype what are really fucking stupid ideas. But that's more marketing and propaganda innovation, rather than technical innovation.

All of the concepts that today are called "NoSQL" were first discovered in the 1970s and earlier. Yes, we've known about these ideas for decades, if not centuries in some cases.

Starting in the 1970s, it was realized that it's important to maintain data integrity, as well as to easily and efficiently query that data. Relational databases were able to provide this functionality.

Fast-forward to the 2000s and 2010s. Now we have web designers pretending to be DBAs and programmers, but they don't know how to use relational databases at all. So instead of learning how to use a relational database properly, they've just re-discovered what everyone else knew of (and wrote off, due to its flaws) decades ago.

They aren't responsible for any innovation or experimentation. They're just decades behind everyone else, knowledge-wise. The new Dark Age they're ushering in is misinterpreted as "innovation" and "experimentation" by fools.

Re:Just in time! (1)

Anne Thwacks (531696) | more than 3 years ago | (#36932410)

mod parent +1 knowledgeable

Re:Just in time! (1)

A nonymous Coward (7548) | more than 3 years ago | (#36932516)

Yes, we've known about these ideas for decades, if not centuries in some cases.

Clue me in. Which of these ideas have we known about for centuries, that the NoSQLers claim to have (re-)invented?

Otherwise I mostly agree with you. I get the impression, for instance, that memcached was invented by Zberg strictly because he couldn't wrap his ego around SQL and thought he was so smart that he didn't need to waste time understanding it.

Re:Just in time! (2, Interesting)

codepunk (167897) | more than 3 years ago | (#36932612)

"Fast-forward to the 2000s and 2010s."

This is the issue, fast forwarding to 2010 we are dealing with scaling and environment issues that your precious relational database cannot solve.

Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.

NoSQL stores are designed to address this sort of scenario not your little app with a hundred concurrent users hanging off of it.
 

Are you for real? You're not joking, are you? (2, Informative)

Anonymous Coward | more than 3 years ago | (#36932778)

This is the issue, fast forwarding to 2010 we are dealing with scaling and environment issues that your precious relational database cannot solve.

Relational databases can scale just fine. It's merely fools like yourself, who are fucking clueless, who have trouble getting them to scale. The problem isn't relational database technology; it's the morons incorrectly designing and implementing the systems who are at fault.

Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.

Well, I would clearly use a real relational database, rather than MySQL. See, using MySQL was your first big mistake. PostgreSQL and Firebird make fine alternatives, and they fit very nicely with your "limited budget" constraint, considering that they're free. Commercial relational database systems work quite well, too, if you're willing to pay a little bit of money.

10 million rows in a single database is absolutely nothing. 10 million rows in a single table is nothing. If you're having trouble scaling with such a small amount of data, then you're doing something seriously, seriously wrong. Whatever it is that you've fucked up, that's yet another mistake on your part. For real professionals, scalability issues usually don't arise until you're dealing with databases containing numerous tables each containing trillions of rows of data.

Of those 300,000 SELECT queries you mention, most are likely unneeded. It sounds like you're just doing a shitty job of caching data. This is yet another mistake you have made.

Only a fool would run a database in a virtual machine that does not provide a proper IO subsystem. If I take the wheels off my car, it's not the car's fault when it doesn't move. Likewise, if you choose the stupidest and most feeble data storage approach possible, it's not the database's fault when IO becomes the bottleneck.

The database you describe can be very easily run, without scalability issues, on most low-end dedicated hosting plans costing a few hundred dollars per year. If your budget so so tight that you can't afford $300 a year, then whatever it is that you're doing is a joke, and the data that you're storing is useless.

(I apologize if your comment was just a joke, and I missed it. Whoosh on me! Sometimes it's just hard to tell when people are joking, and when people are seriously advocating NoSQL techniques. Both involve a similar style of ignorance. In the professional DBA case it is feigned, but in the NoSQL advocate case it is real, pure, honest-to-goodness ignorance.)

^------ THIS (1)

malakai (136531) | more than 3 years ago | (#36933646)

...THIS...

RDMS Scale poorly because of poorly trained dev/admins. I've walked into 10s of shops and _laughed_ at their production RDMS. They would throw hardware at a problem that was from the outset simply poorly engineered. in fairness, most of these VLDB systems were built by glorified 'power' users who just kept hacking away at a problem. Bravo to them for making something work, but at some point when your whole business depends on this intern-built multi-TB database, you need to bring in an expert.

You don't need lots of $$$ to handle VLDB these days. You just need to understand the individual throughput and bottlenecks of the complete solution.

Also, once you understand and properly implement horizontal partitioning, the number of records in your table really doesn't matter.

Re:Just in time! (1)

Joe U (443617) | more than 3 years ago | (#36932816)

Tell me mr genius how you are going to handle 300k select queries on you mysql database holding 10 million rows, running on a virtual instance with shitty IO. Now add the fact that you have a very limited budget etc.

There are scenarios where NoSQL is a valid alternative, this is not one of them.

Re:Just in time! (1)

Splab (574204) | more than 3 years ago | (#36932966)

10 million rows? That should fit in most database servers main memory.

Oh, and if your I/O is the trouble, NoSQL wont magically make it disappear.

The only thing NoSQL has solved is doing multimaster cheap, yes those are hard to solve in traditional databases, however, you can only solve it, if your datamodel is ok with eventually correct, most business aren't.

Re:Just in time! (1)

tgv (254536) | more than 3 years ago | (#36933524)

If you're willing to spend a lot of money, perhaps. But if you want to run on the cheap, where you've got more time than money, NoSQL database provide excellent performance. I'm working with an Oracle Enterprise installation, and it just cannot compete with the 30M rows that the Hypertable db on my laptop can serve up in a couple of seconds. Perhaps if the DB guys threw a load of money at it, Oracle could do that too. However, using Hypertable means that you have to write a lot of extra code. That's not good for business in the long term. But for a start? Or for throwaway data (I'm thinking Twitter)?

PDF version of paper (2)

gmueckl (950314) | more than 3 years ago | (#36932178)

Re:PDF version of paper (1)

ggy (773554) | more than 3 years ago | (#36932226)

But to the wrong paper, as stated in TFA.

Wrong link in the summery? (4, Informative)

ggy (773554) | more than 3 years ago | (#36932208)

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/ [unqlspec.org] ?

Not standard, unified. (3, Funny)

pedantic bore (740196) | more than 3 years ago | (#36932218)

"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:Not standard, unified. (1)

arglebargle_xiv (2212710) | more than 3 years ago | (#36932950)

"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."

Then all they need to do is reinvent ACID and they'll have made it to the 1980s. At that point they'll only have another thirty years of catching up left to go...

get(key) (1)

codepunk (167897) | more than 3 years ago | (#36932260)

The beauty of a nosql store is defined by this query method get(key) it need to be nothing more and nothing less than that. Adding a query language totally defeats this purpose. Not to mention once you commit to using a search mechanism you are tightly bound to it.

For instance I use mongodb but I do not allow anyone to use it's built in search mechanisms other than find by some key within the app itself.

Sticking to this rule allows us to move to something like pure memcached, membase etc as a store by a simple config change.

Now using search capability outside the app is handy but again tightly binds you to the platform.

Re:get(key) (0)

Anonymous Coward | more than 3 years ago | (#36932464)

I've heard a lot of pretty stupid shit out of the NoSQL community, but my word, you've taken it to a whole new level.

Re:get(key) (1)

purpledinoz (573045) | more than 3 years ago | (#36932938)

Searching is for pussies. Real men memorize every unique key in the database.

I don't get it... (0)

Anonymous Coward | more than 3 years ago | (#36932304)

Well, call me crazy, but the idea of NoSQL was NOT USING SQL AT ALL... now we got a language that in FACT "could be considered a superset of SQL", ok now we have to learn SQL and MORE to use a NOsql set of data. Great but let's change the name of NoSql to something else because this is more st..p thing I heard in the last years... now what.. people is going to hand out meatballs at PETA meetings ....

Re:I don't get it... (1)

luis_a_espinal (1810296) | more than 3 years ago | (#36932630)

Well, call me crazy, but the idea of NoSQL was NOT USING SQL AT ALL... now we got a language that in FACT "could be considered a superset of SQL", ok now we have to learn SQL and MORE to use a NOsql set of data. Great but let's change the name of NoSql to something else because this is more st..p thing I heard in the last years... now what.. people is going to hand out meatballs at PETA meetings ....

Crazy? No. Ignorant. Yes. In essence "the idea of NoSQL was NOT USING SQL AT ALL" is simply not true. This has been mentioned for a while now, but apparently people can't seem to grasp it. NoSQL is a misnomer since the idea is not to move away from SQL but to provide data models alternative to Codd's relational model for a variety of reasons (high availability is just one of them.) I agree that the name needs to be changed, but I'd also say that Google is your friend.

what's new? (0)

Anonymous Coward | more than 3 years ago | (#36932324)

am i missing something or is this just same old sql, what exactely is new here? no map/reduce?

Superset of SQL (0)

Anonymous Coward | more than 3 years ago | (#36932340)

UNQL, for a post-relational world. Nice. Meanwhile 90% [citation needed] of people working with databases can't even get relational databases right.
Learning to run before learning to walk, anyone?

Re:Superset of SQL (1)

luis_a_espinal (1810296) | more than 3 years ago | (#36932672)

UNQL, for a post-relational world. Nice. Meanwhile 90% [citation needed] of people working with databases can't even get relational databases right. Learning to run before learning to walk, anyone?

And we are moving into functional and functional-object-hybrid models of programming when the majority of programmers in 2011 cannot even do structured programming, and try every single way to break the Bohm-Jacopini Theorem using whatever du jour OOP language of the day. So what's your point?

If we had to wait for every moron code monkey to come up to speed, we would still be reading data off punch cards using a bastard mix of COBOL and mainframe assembly. Industrial and academic R&D and innovation forces have an obligation to move forward. Individual programmers have an obligation to educate themselves and to develop the work ethics to do things right wherever and whenever possible. Lack of the later is not reason to bog down the former.

Re:Superset of SQL (1)

purpledinoz (573045) | more than 3 years ago | (#36932984)

The Structured Programming Theorem (redirected from Bohm-Jacopini Theorem) from Wikipedia states: The structured program theorem is a result in programming language theory. It states that every computable function can be implemented in a programming language that combines subprograms in only three specific ways. These three control structures are:

1. Executing one subprogram, and then another subprogram (sequence)
2. Executing one of two subprograms according to the value of a boolean variable (selection)
3. Executing a subprogram until a boolean variable is true (repetition)

How does one exactly break this theorm?

Wrong spec link in article (1)

CNeb96 (60366) | more than 3 years ago | (#36932500)

The link to the spec appears to be http://www.unqlspec.org/ [unqlspec.org] not http://wwww.unqlspec.org/ [unqlspec.org] as shown in the article, which appears to just a site about couchbase.

And In Other News... (1)

MightyMartian (840721) | more than 3 years ago | (#36932548)

And in other news, wheel reinvented, news at 11.

SPARQL (1)

TuringTest (533084) | more than 3 years ago | (#36932552)

So, this is better than existing unstructured languages like SPARQL [wikipedia.org] , how?

Re:SPARQL (1)

21mhz (443080) | more than 3 years ago | (#36933550)

SPARQL belongs to the RDF la-la land, so it's designed by academics who never tried to implement anything convenient and scalable.
Just ask them how easy it is to store and query a semantic equivalent of an ordered list of strings.

I will say it now... (1)

cjjjer (530715) | more than 3 years ago | (#36932556)

CouchDB, SQLite and Microsoft are shepherding the project and are inviting other parties to participate. "We're not trying to drive some sort of heavyweight process," Phillips said. Future versions of both CouchDB and SQLite will support UnQL queries, their creators promise.

Somehow I feel that MS will be either buying up of these NoSQL companies or is developing their own in the near future. Why else would MS get involved...

Re:I will say it now... (1)

Noughmad (1044096) | more than 3 years ago | (#36932702)

Why else would MS get involved...

Because nobody wants SQL Server, and they need to spread some more FUD about its competitors.

Re:I will say it now... (1)

sgt scrub (869860) | more than 3 years ago | (#36933712)

I doubt that. Microsoft's extend and embraced version of SQL has XML support using XQuery. They are obviously looking for someone like Sybase, the origin of msSQL, to unify the sql language to handle queries on both XML and Relational Data without switching languages. I mean really, how else can Microsoft "invent" it?

Truly fascinating (1)

jasomill (186436) | more than 3 years ago | (#36932568)

What I don't get is why they're adopting something modeled on one of the key weaknesses of traditional relational database management systems. "Familiarity," perhaps, but this seems likely to be superficial, and the stated goal of "creat[ing] some form of commonality among non-SQL databases" strikes me as similar to the goal of finding "some form of commonality among non-elephant mammals."

That there exist applications for data storage where a relational database isn't the appropriate tool is trivial, and well-understood by the relational database community, as is the fact that integrity guarantees are not, in general, available "for free." This has nothing at all to do with one's choice of query language, incidentally.

The whole "NoSQL" thing strikes me as an attempt to use straw man arguments to drum up publicity, which, as I pointed out in response to another article, can be quite brilliant if done artfully [snopes.com] . Unfortunately, the NoSQL community is hardly Groucho Marx, and the relational database "establishment," taken as a whole, is hardly comparable to a bunch of money-grubbing, back-stabbing studio executives.

The result, predictably, seems to be even more misinformed skepticism in a field already full of it, sort of like Twain's line about "lies, damn lies, and statistics" being mistakenly invoked as a general indictment of mathematical modeling (and, by extension, most of empirical science).

What a major f* fail in citations (3, Informative)

luis_a_espinal (1810296) | more than 3 years ago | (#36932574)

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 [arnnet.com.au] , called UnQL (Unstructured Data Query Language [psu.edu] .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 [acm.org] , 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...

Quick! Somebody tell... (1)

kgeiger (1339271) | more than 3 years ago | (#36932608)

the CODASYL people they've fresh meat.

NoSQL language based on SQL? (1)

chimerafun (1364591) | more than 3 years ago | (#36932656)

It's a superset of SQL with extra operators? So NoSQL has become SQL? {face palm}

NoSQL DB's are a "rehash" (pun intended) of (0)

Anonymous Coward | more than 3 years ago | (#36932992)

Of ISAM/VSAM DB engines, which also use Hash Tables vs. B-Trees (what Relational DB's use), so your point was what?

* My take on "NoSQL" DB's is they are a rip-off (or more politely, an "evolution") of ISAM/VSAM stuff IBM was doing ages ago in databases, because of their foundations designs noted above (& largely, the Windows filesystem + registry use a similar concept also iirc).

APK

P.S.=> In the end? Well - Everyone's "building & standing on the shoulders of GIANTS before they" (in other words, reaming ideas/stealing, but... making each iteration better than the last one, hopefully)...

SO, who gains?

Well, we, the end users (that's ALL OF US, everyone IS A CONSUMER), who are, after all, THE IMPORTANT ONES really!

(They're/We're the "customers" & consumers of said products, which is every one of us, & who hopefully PAY for the wares keeping an economy moving (this point? Well, it is 1 of the parts I don't like about "Open SORES" really because FREE can harm economic monetary movements between hands IF you *think* about it... but oems/manufacturers like it because, as in the case of routers, it keeps "per unit" co$t$ down, because the underlying OS or DB engine is "FREE" as in beer etc./et al))...

... apk

That leads to question (0)

Anonymous Coward | more than 3 years ago | (#36932728)

How many years we have till NoUnQL movement?

Microsoft Backing Database Projects (1)

The O Rly Factor (1977536) | more than 3 years ago | (#36932772)

Step 1: Structured query databases exist for four decades, show they are perfectly capable of scaling, load balancing, and anything else you want them to do.

Step 2: Microsoft writes a structured query database, it can hardly do any of these.

Step 3: "Rararara structured query sucks lets support some half-baked DB idea and as soon as there is a breakthrough buy it up."

Step 4: ???

Step 5: Profit!

Advocacy of NoSQL is a warning sign... (1)

aristotle-dude (626586) | more than 3 years ago | (#36932780)

Shitty programmers who cannot be bothered to learn how relational databases work or seem to be completely oblivious to the fact that they are paid to create systems that not only serve the front end consumer user but also people on the backend business side would advocate NoSQL. If the product/service you are writing has anything to do with money, business users need to have information stored in a relational model that can be easily queried or extracted into a data cube for business analytics. This is why you have data translation layers with data transformation objects (DTOs) in the first place to translate your object model into a relational model and back again.

If you work for a "for profit" company that deals with customer and sales data in any capacity then you need to have people competent people working who have at least a basic understanding of the relational model and transactions. If you work for one of those companies and are advocating NoSQL for data that the business needs for data mining or processing sales then you should either be reeducated or offered the door because you have forgotten who your actually work for.

Re:Advocacy of NoSQL is a warning sign... (0)

Anonymous Coward | more than 3 years ago | (#36933048)

IBM and Oracle, among many others, have in-memory data grid products which give provide the benefit of storing data in memory for quick access and also provide a way to store data in a relational database in the background. Put an object in the in-memory data store and at some specified point in the future (X transactions later or X seconds later) it will be loaded into the relational database.

In most cases the data grid products give much better read/write performance than the database. The data grid acts as a read-through/write-through cache. In order to get the most out of the grid a programmer may need to rethink their object model in order to ensure and preserve locality of reference. From there, data mining can be done as usual on data in the database.

The tools for data mining from a relational format are mature and work. The same can not be said of tools that do this from a NoSQL format because they don't exist yet. IBM and Oracle, our two largest database vendors, offer data grid products. They seem to believe there is something to the best of both worlds approach.

I do not work for any company that creates/sells/distributes in-memory data grids. I have only used them in past projects and got fantastic results.

Re:Advocacy of NoSQL is a warning sign... (1)

russellh (547685) | more than 3 years ago | (#36933102)

Yeah that's great when your data fits the relational model.

Re:Advocacy of NoSQL is a warning sign... (0)

Anonymous Coward | more than 3 years ago | (#36933458)

If your data doesn't fit "the" relational model, get a better model. Or a better modeler.

Re:Advocacy of NoSQL is a warning sign... (1)

tgv (254536) | more than 3 years ago | (#36933536)

And if your data doesn't fit in a relational database, how are you going to get it into a noSQL one? Writing serialized data in the value field?

Re:Advocacy of NoSQL is a warning sign... (1)

FooBarWidget (556006) | more than 3 years ago | (#36933598)

Or maybe said "shitty" programmer:
- is writing a for-profit web app for his own company that consists of mostly programmers
- already knows in advance that the only queries he's ever going to make are those defined by the programmers, and that for his particular use case it's no disaster if newly introduced queries only work over new data
- already knows in advance that his data size will become several terabytes in several months and thus needs sharding
- does not want or have the resources to spend several million dollars on expensive Oracle licenses

Go ahead. Find me an auto-sharding solution for MySQL or PostgreSQL that doesn't involve tons of money. Then I'll change my mind.

The Spec (1)

hey (83763) | more than 3 years ago | (#36932936)

http://www.unqlspec.org/display/UnQL/Home [unqlspec.org]
Wow took a lot of looking around!

Re: The Spec (1)

spacey (741) | more than 3 years ago | (#36933184)

This is a soft-sell way to get nosql databases into traditional IT situations, where familiarity with SQL will let current support and DBAs say "oh, it's like SQL, but it doesn't have joins. I can do that".

I always did like the sqlite docs, specifically the diagrams of the state machine for each statement.

NoSQL SQL .. ARG!!!! (0)

Anonymous Coward | more than 3 years ago | (#36933296)

I have been trying to figure out what exactly is the difference between relational and NoSQL data models.

And, I still don't fully (or at all really) understand them. CAN SOMEONE PLEASE EXPLAIN THE DIFFERENCE

OR at least give me a link to a well thought out explanation with some examples in it?

Honestly, this all sounds like new coke to me

But, I also know that I am not getting something

Re:NoSQL SQL .. ARG!!!! (0)

Anonymous Coward | more than 3 years ago | (#36933580)

NoSQL databases, especially MongoDB, tend to be more web scale.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>