Forgot your password?
typodupeerror
Databases Microsoft

Unified NoSQL Query Language Launched 194

Posted by timothy
from the ontogeny-recapitulates-phylogeny dept.
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."
This discussion has been archived. No new comments can be posted.

Unified NoSQL Query Language Launched

Comments Filter:
  • by chriswaco (37809) on Saturday July 30, 2011 @09:26AM (#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.

  • by Anonymous Coward on Saturday July 30, 2011 @09:38AM (#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.

  • by luis_a_espinal (1810296) on Saturday July 30, 2011 @10:06AM (#36932486) Homepage

    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

  • by Anonymous Coward on Saturday July 30, 2011 @10:29AM (#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.

  • by gfody (514448) on Saturday July 30, 2011 @05:38PM (#36935316)
    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?

If it's worth doing, it's worth doing for money.

Working...