Become a fan of Slashdot on Facebook


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

Unified NoSQL Query Language Launched

Comments Filter:
  • by ggy (773554) <eric,aili&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 [] ?

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

  • 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 [], 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...

  • by Joey Vegetables (686525) on Saturday July 30, 2011 @10:47AM (#36932688) Journal
    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.
  • by Anonymous Coward on Saturday July 30, 2011 @11:03AM (#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.)

egrep -n '^[a-z].*\(' $ | sort -t':' +2.0