Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Unified NoSQL Query Language Launched

Comments Filter:
  • by Daetrin (576516) on Saturday July 30, 2011 @08:32AM (#36931988)
    Standards [xkcd.com]
    • by Pieroxy (222434)

      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.

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

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

    • by ianare (1132971)

      FTFA :

      UnQL, pronounced "Uncle"

    • No flamewar necessary. Oracle is the new evil overlord.
      Having backing from Microsoft just makes it irrelevant.
      • by Jonner (189691)

        No flamewar necessary. Oracle is the new evil overlord.

        Having backing from Microsoft just makes it irrelevant.

        I'm sure Oracle would be offended by your implication that they've only recently become evil.

    • by hedwards (940851)

      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.

    • by Jonner (189691)

      I've always thought "NoSQL" is a dumb term and idea because it's nothing more than a negative position. Its proponents seem to be anti-SQL, though not necessarily for all the same reasons. In many cases, people seem to be equating SQL with the relational model and abandoning the latter because of deficiencies in the former. UnQL seems to be bringing things full circle in that its designers realize that there's no sense in abandoning the relational model and all work done on query languages so far. It's incr

  • by VincenzoRomano (881055) on Saturday July 30, 2011 @08:58AM (#36932136) Homepage Journal

    It has Microsoft's backing."

    It won't work.

    • by KiloByte (825081)

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

      • To hell with that, I've been pushing MongoDB and NodeJS as a means for a unified language... JS everywhere (we do a lot of Flash/ActionScript work too). Not taking a slide back if I can avoid it. Have 3 pretty big projects coming up, one of which just screams use node/mongo given the use case, and data needs. UnSQL really seems like an attempt for MS & CouchDB to have their standard (probably a bastard cross between OData and the current couch interfaces).
    • Won't work as a language, or as a way to generate revenue? I'm guessing that Microsoft is more concerned with the latter.

  • 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 c

    • Not if it's a bastard cross between Couch's interface and OData... I really wouldn't want that. I happen to like the MongoDB interfaces. The largest issue is that different NoSQL systems have different features that a unified interface can't/won't cover because of their nature. Migration paths are fine, but with document-centric data, moving is easier than switching differing SQL based data stores, as someone who's worked on a migration from Sybase to Oracle, and another from DB2 to MS-SQL, it isn't fun.
    • Wait, wait, wait... I thought the whole point of NoSQL was that not only were you able to free yourself of schema's and traditional DB related fluff, but you got a subset of features that were tuned to a specific range of use cases.

      The fact that NoSQL has no standard level of commonality between implementation has provided fertile ground for programmers to enhance what they feel is important. If we standardize NoSQL then people will begin to focus more on the core functions than the fringe functions, at s

  • by Angst Badger (8636) on Saturday July 30, 2011 @09:01AM (#36932152)

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

  • by ggy (773554) <eric.aili@noSpam.gmail.com> on Saturday July 30, 2011 @09:11AM (#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] ?

  • by pedantic bore (740196) on Saturday July 30, 2011 @09:13AM (#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."

  • 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 sim

    • by Jonner (189691)

      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.

      Yeah, I yearn for that beauty when I use PostgreSQL. If only I had to write pages of new application functionality every time I wanted to search in a different way or add a new kind of thing to my database. Who wants to write a couple of lines of SQL when you can write hundreds of lines of C++?

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

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

    • by 21mhz (443080)

      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.

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

    • by Noughmad (1044096)

      Why else would MS get involved...

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

    • by sgt scrub (869860)

      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?

  • by luis_a_espinal (1810296) on Saturday July 30, 2011 @10:22AM (#36932574) Homepage
    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...

  • 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!
  • 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

    • by russellh (547685)
      Yeah that's great when your data fits the relational model.
      • by tgv (254536)

        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?

      • by Jonner (189691)

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

        What's your hypothetical data that can't be represented relationally? I haven't come across anything like that yet.

    • 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 m

    • You must have limited experience, relational model fits only set-based data well. There are plenty of hierarchical data structures for which the relational model is a terrible fit and give abysmal performance for both storage time and queries. I've seen this time and again in my three decades of working with relational databases. A client of mine has been working with medical AI systems for a few years, one early discover was relational model is absolutely an inferior representation for most knowledge b
      • by Jonner (189691)

        You must have limited experience, relational model fits only set-based data well. There are plenty of hierarchical data structures for which the relational model is a terrible fit and give abysmal performance for both storage time and queries. I've seen this time and again in my three decades of working with relational databases. A client of mine has been working with medical AI systems for a few years, one early discover was relational model is absolutely an inferior representation for most knowledge base ontologies,

        The relational model fits hierarchical data just fine. It's only the awkwardness of SQL that was holding you back or the particular implementation if queries were too slow. Is any of your experience based on a non-SQL relational language?

    • by codepunk (167897)

      I know google is all fucked up they should run their search engine on oracle rac.

      NoSql solutions are for extreme transaction rates on cheap or virtual hardware. It has nothing to do with not knowing how a database works. It has everything to do with how I am going to get sub second response with transaction rates in the 100s to thousands per second.

      Not everything or every application fits into your perfect little view of the world.

    • by Jonner (189691)

      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.

      It has nothing to do with "for profit" status. I work for a non-profit and work with a relational database all day. Observe how widely SQLite (which always has been a relational, SQL-based DBMS) is used, from Firefox to most smart phones. People who know how to use relational databases know they save a lot of development time which would otherwise have to be spent reinventing many wheels.

      One area that needs work is language design, since SQL is far from ideal. I'm convinced that most of the complaints NoSQL

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

    • by spacey (741)

      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.

      • by Jonner (189691)

        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.

        If the DBAs think it's acceptable to lack joins, perhaps they should look for another job.

Too much of everything is just enough. -- Bob Wier

Working...