Forgot your password?
typodupeerror
Databases Programming Math

SQL and NoSQL are Two Sides of the Same Coin 259

Posted by Unknown Lamer
from the dualistic-monadic-monsters-from-the-sea dept.
An anonymous reader writes "NoSQL databases have become a hot topic with their promise to solve the problem of distilling valuable information and business insight from big data in a scalable and programmer-friendly way. Microsoft researchers Erik Meijer and Gavin Bierman ... present a mathematical model and standardized query language that could be used to unify SQL and NoSQL data models." Unify is not quite correct; the article shows that relational SQL and key-value NoSQL models are mathematically dual, and provides a monadic query language for what they have coined coSQL.
This discussion has been archived. No new comments can be posted.

SQL and NoSQL are Two Sides of the Same Coin

Comments Filter:
  • by JonySuede (1908576) on Thursday April 07, 2011 @05:48PM (#35750848) Journal

    microsoft research rocks but the product division usually sucks !

    • by jbolden (176878)

      I agree. Their research division is amazing. If they implemented 10% of what came out of their research division they would have the coolest sites around.

    • by Draek (916851)

      No, just their software. Their mice and keyboards are second to none, and I know more than a few gamers that wouldn't touch an X360 with a ten-foot pole but still keep one of its controllers plugged in their PCs.

      • by nschubach (922175)

        I've loved my Logitech mice/keyboards way more than any MS hardware. (I think there was even a point early on when Logitech made MS mice?)

        Also, wouldn't touch a 360, nor the controller.

      • by CastrTroy (595695)
        Obligatory Penny Arcade [penny-arcade.com]. The original XBox controllers were terrible.
        • by billcopc (196330)

          Obligatory bullying: The original XBox controllers were PERFECT! You just have wussy little hands.

          I could never get used to the smaller controller, nor anything from the Playstation camp. My fingers just aren't made to clamp down on such tiny things.

    • by smash (1351)
      10 years ago I'd agree. They've really picked up their game in the past 5 years though.
  • by 0p7imu5_P2im3 (973979) on Thursday April 07, 2011 @05:51PM (#35750874) Journal
    An inverse tachyon pulse would disperse the relational quantum silica into a focused warp field, thus purging all forms of slipstream space based SQL databases from subspace.
  • by MrEricSir (398214) on Thursday April 07, 2011 @05:56PM (#35750926) Homepage

    ...is that SQL sucks as a language. It's not terribly expressive, the ordering of arguments is inconsistent, and whoever designed the way JOIN works should be in jail.

    Frankly, I'd like to see SQL die and get replaced with something more modern. We don't program in Cobol anymore, so why the hell are we still using SQL?

    • by Anonymous Coward on Thursday April 07, 2011 @06:05PM (#35750980)

      so why the hell are we still using SQL?

      Why are we still using C? Why are we still using HTML? Why are we still using FORTRAN (in the scientific community)? Same reason.

      Might add that all these - C, HTML and FORTRAN - are still being updated, with new standards. So is SQL. It's really the same thing, and they all stick around for the same reasons, too.

    • by sexconker (1179573) on Thursday April 07, 2011 @06:10PM (#35751024)

      We DO still program in COBOL.
      And we DO still use SQL.
      And we do so because it works.

      Not only does SQL work, it is the best at what it does.

      The only people who hate on SQL are the people who don't understand databases.
      Generally, these are the same people who like labels, tag clouds and ruby on rails.
      They produce a lot of high level hand waving with regards to the actual code and endless amounts of "herp derp I dunno" when asked why their shit performs slower than the 10 year old system it's supposed to replace. These are bad people.

      What really pisses me off is that everyone fucking agreed with me until Android came out, then suddenly Java was cool, the performance was considered "good", and the quality of code and coders that it tends to bring about is now the acceptable norm.

      • Here, here. Wish I could give you some mod points.
      • by MrEricSir (398214)

        The only people who hate on SQL are the people who don't understand databases.

        That's a lot like saying people who don't like washing their clothes by hand don't like wearing clean clothes. Just because you enjoy doing something in a painful way doesn't mean that it's the best way to do it.

        • Re: (Score:3, Insightful)

          by DogDude (805747)
          It's not painful. It's just different than what web developers doing "select *" are used to. As a system, it works well for tiny projects, all the way to the largest databases in the world. In the world of "develop it now, deal with problems later", people just can't be bothered to learning the right way to do something.
      • There are a few things with SQL that could be done better, and there's still some standardization needed. I'd like to see a SQL 2012 standard or something.

        But you're entirely right. There is one place nosql makes sense, and it's gigantic data stores like facebook and google, where the quantity is overwhelming, and the quality isn't that important...it's okay miss a few things, and you're looking for sorta-random stuff. That is why NoSQL was invented.

        No one should ever 'choose' to use NoSQL...if you're on the size of a project that needs NoSQL, I promise you you are nowhere near that decision...it will be decided between the seven project architects as they buy thirty servers to run the damn thing. That's the guys who have a legit need, or at least it's a legit option, of using NoSQL.

        It's not useful for any other system in existence.

        It's especially funny when toy projects try to use NoSQL. It's like idiots trying to run their watches off geothermal power. 'It's free power! FROM THE EARTH!'

        Dude, you're using half an amp, perhaps you should learn how to use a watch battery instead of driving 2 mile polls into the ground as you walk around. It's not like SQL is fucking rocket science. In fact, right now, NoSQL is actually more complicated to use.

        • by Sarten-X (1102295)

          And yet, one of my toy projects in grad school generated over a billion data points that needed analysis. The only database server I had access to choked on the first analysis pass (of about a dozen). It took about three months of processing to get to a point that could even be considered acceptable. Since then, on a whim, I've redone the program using Hadoop and HBase. A MapReduce job completed the analysis, on worse hardware, in less than a day. A major contributing factor was the lack of a rigid structur

          • Could I pick your brain since you have a bit of NoSQL experience?

            How does indexing work in NoSQL? Are there EXPLAIN-type tools available? (EXPLAIN in MySQL tells you whether your query is using indexes or table scans, and can help you understand why your query is slow.)

            I'm pretty flexible with SQL. Can you do just about any query you could with SQL? ("Find all customers who have bought at least $100 of stuff over the last year, but who haven't bought anything this year.")

            • Re:using noSQL (Score:5, Interesting)

              by Sarten-X (1102295) on Friday April 08, 2011 @02:50AM (#35754384) Homepage

              Yes, no, and yes, in that order. I'm basing my answers on HBase, with which I have the most experience. My answers are also practically guaranteed to be wrong in somebody's eyes, because HBase is so much more flexible than an RDBMS. If I describe one way of doing something, another layout may work just as well, and somebody's going to favor that way.

              How does indexing work in NoSQL? Are there EXPLAIN-type tools available?

              EXPLAIN tools aren't really necessary in HBase, because almost all nontrivial queries are a scan over a small chunk of the alphanumerically-sorted rows. It will take a while, but please allow me to explain. Each row is a multi-value key-value store, with each value having a column name. If you really want to stick to the RDBMS style, you could have your key be a numeric row ID, and scan everything for every query. It would suck, because you're not using any indexes.

              Indexes are more or less left up to the programmer. Creating an index is effectively just adding more rows to the table. For example, that RDBMS-style layout in the last paragraph could be a table of ID numbers, usernames, passwords, and permissions (for 50 billion people, I guess...). For whatever business reason, the main key will be the ID number. Those rows are easy. They have the expected value columns: username, password, permissions. To index by username, we add new rows, with just a column for the ID number. We could just duplicate the data, but let's not. Now, our table is going to be huge, but sparse. Half of the rows have three of four columns filled, and the other half has only one. Searching by name, it'll take two requests to get to the actual row we want, but that's okay. Doubling the amount of work lets us run faster.

              The reason for that is HBase's split design. HBase's table is split into column families and regions. Column families are a means to group columns, so that even on data with overlapping key space, separate data could remain separate. Column families are stored as separate files in Hadoop. In our example, the username "index" could be a separate column family. That could speed up scanning, because the rows keyed by numeric usernames won't be interspersed with the rows keyed by user id. More importantly, the table is split into regions, each containing a number of rows. Those regions are also stored as separate files, and distributed across the entire Hadoop cluster.

              The cluster is really where Hadoop gets its speed. If we were to run all of our processing from one central location, it would be horribly slow and require a ridiculous number of requests. Instead, we'll distribute everything, including the query, similar to how some RDBMS sharding schemes work. We send a request to all nodes, asking for "the row with the key that matches the value of the 'userid' column of the row with a given key". Each node will report back its results. Unlike RDBMS sharding, the partitioning is handled automatically by HBase into regions that are optimal. It's these regions that are scanned for every request.

              After all of that, it should be quite clear: With HBase, the programmer is expected to know the layout of the data, and write requests based on the key. There is no EXPLAIN tool, because everything is just a key-value lookup.

              Whew. Next question...

              Can you do just about any query you could with SQL?

              Yes, but it's different. Every lookup is handled by scanning a region (in parallel on nodes that have that region's data files), and checking each column of each row to see if:

              1. The row key matches what was requested, or falls within a given range.
              2. The row contains a column that was requested.
              3. A given filter approves each column.

              Note that last item. The filter is simply a program that tells Hadoop whether the row (or some part of it) should be included in the returned results. That program can include other HBase requests, using other filters. If you're really stuck on using RDBMS

          • by DavidTC (10147)

            Uh, I know you're trying to push NoSQL, but under no definition of 'toy' is included a billion data points.

            In my opinion, it's worthwhile to be familiar with both, and to be able to choose the right one for every task.

            Yes, just like taxi drivers should be familiar with passenger cars and the 3000 tonne Space Shuttle Crawler [wikipedia.org]. Because sometimes people need to move the space shuttle.

            It's just obvious. Everyone should aim to be skilled in the actual tool everyone uses all the time, and an incredibly special

            • by Sarten-X (1102295)

              under no definition of 'toy' is included a billion data points.

              From WordNet:

              My project was done in my spare time, with no funding from anyone but myself, for the purpose of my own entertainment and education. I believe that's a reasonable candidate for a "toy". It was a web crawler that scanned a few thousand websites (top hits on Google for various terms) and analysed their connections to each other. My goal was to see what sort of relationship "reputable" sites (like CNN, for example) had to "disreputable" sites (4chan), in the hope that there'd be a way to gauge a s

        • by k8to (9046)

          Funny, as I fire up my mutt mail client and instantly open enormous mailboxes by that are backed by nosql caches in tokyocabinet. I guess my personal mail is really a problem that requires 7 architects and 30 servers.

          Oh wait...

          Yeah, you could do this with a sql engine, like postres, or an in process sql approach like sqlite, but the keyval store actually maps much more closely to the problem, and the memory consumption is kept *very* low even for hundreds of thousands of messages. Just bringing postgres u

          • by DavidTC (10147)

            tokyocabinet and other dbm are not what people are talking about when they say NoSQL. 'NoSQL' does not mean 'database engine that doesn't use SQL'.

            NoSQL would be better called 'NoRel'. NoSQL is a non-relational database. And NoSQL is only available as a database server, which I assure you have no less memory requirements than SQL servers. (And if you're having trouble imagining what the hell a 'non-relational database' is, or would be used for, you're not alone.)

            Whereas dbm libraries like tokyocabinet are

            • by DavidTC (10147)

              Actually, thinking about it, gdbm, and I assume tokyocabinet, are not technically relational, it's just everyone uses them as such by storing identically shaped records and attaching hash tables to them so people can find things.

              What people are complaining about here are things like HBase and Hypertable, not dbm libraries.

              They have all the disadvantages of dbm libraries (Like non-records taking up space), and all the disadvantages of SQL servers (Like having to copy things around in memory), and extra dis

      • Re: (Score:3, Informative)

        by lakeland (218447)

        And we DO still use SQL. And we do so because it works

        I disagree.

        There are some things which are fast for a computer to do but are slow and awkward to do in SQL. You can see quite a few of them in SAS supported by data steps (e.g. decent RBAR support). Another is say I want to get the latest transactions for each customer, I have to do something like

        select customer_id,max(txn_datetime) latest_txn_datetime
        from fact_txn
        group by customer_id

        -- I've now got the latest transaction time but because system reversals and the like are often set to happen at the same t

        • Lol,

          that was water on the wheels of the other posters you agree: most people have no clue about programming and SQL.

          If one of your main use cases is to find the "latest transaction" of your customer, then adapt your database to support that use case.

          Sorry, your example makes no real sense at all.

          angel'o'sphere

          • by geekpowa (916089)

            Actually, the example makes perfect sense and it is a problem I've encountered regularly and one of my many bug bears with SQL.

            The generalized problem is 'find last txn' for every customer before date X.

            Now if you can access the btree directly, you can efficiently walk it and get this data. But with SQL you cannot efficently get it. PostgreSQL windowing functions make getting such data simple in terms of constructing the SQL (once you get your head around windowing functions), but these queries walk la

            • But that is not a problem of SQL!!!

              It is a problem of relational data bases.

              So use an OO database if you need to do that, e.g. Or as this discussion is about: a noSQL one.

              Or do what the smart guys do: save the stuff partly in a relational one and partly in an RDBMS.

              Blaming a language because it can not express what you want/need makes no sense at all. Use a language/system that can, instead.

              angel'o'sphere

              • by geekpowa (916089)

                I am loving this thread. People who appear to know little about the underlying mechanics of how databases perform coming forward and saying 'use magic elixir X!'. OO databases to solve this problem? Are you serious and do you even know what you are talking about? An 'OO' database is just a relational database that includes a notion of inheritance. i.e. PostgreSQL. Though it may be possible that you may be talking about something radically different, in which case how about you point me towards some links

                • An 'OO' database is just a relational database that includes a notion of inheritance. i.e. PostgreSQL.

                  No, that is an Object Relational Database.

                  An OO Database e.g. is http://www.orientechnologies.com/orient-db.htm [orientechnologies.com]
                  or http://www.versant.com/ [versant.com] or ObjectStore or GemStone.

                  Your previous post screamed for an oo database. Now you say I have no clue ... up to you ;D solve your problems yourself then.

                  angel'o'sphere

                  • by geekpowa (916089)

                    Thanks for the links. Look like interesting products.

                    I did not mean to come off as rude, but I did. My apologies. In prior post you said "But that is not a problem of SQL!!! It is a problem of relational data bases.". Can you please clarify this/point me towards a clarified. It is not evident to me how a object graph database somehow provides a efficient and meaningful solution to this specific generalised problem and how precisely it does this presumably by avoiding some unstated limitation of RDBMS.

            • by nahdude812 (88157) * on Friday April 08, 2011 @06:57AM (#35755388) Homepage

              Like Angel'o'sphere said, if you can adapt your database, the problem becomes trivial. Make sure that at least for a given customer, each subsequent transaction ID is greater than the prior transaction ID (if this is not already the case, then add a new field populated by a sequence so that you have a field where it is the case).

              Here's the solution with a sub-select (because it's easier to read, it can be converted to a join for efficiency):
              SELECT
                      transactions.fieldNames
              FROM transactions
              WHERE
                      (transactions.customerID, transactions.transactionID) IN (
                              SELECT customerID, MAX(transactionID)
                              FROM transactions
                              GROUP BY customerID
                      )

              If, as you suggest, you need it for specific date ranges, then add those to the sub-select. Like I said, for most RDBMS's this would be faster if converted to a join (and basically every sub-select can be converted to a join). For some RDBMS's they would convert it to a join as part of the execution planning anyway (I believe Postgres and Oracle do this).

              Arguments like these actually only serve to strengthen RDBMS's case over NoSQL. Database engineers have been solving these problems easily and efficiently for years, but a new generation likes to think in new patterns. Not that there's anything wrong with that - except there is a certain tendency to try to put a square peg in a round hole, a complaint when it doesn't fit right, and a sigh from the guys who've been carving pegs so they fit snugly all along.

              Key/value storage does have advantages over traditional RDBMS designs (assuming the RDBMS is designed and utilized properly), but those advantages are things like linear scalability, and very few cases where a task on the K/V side is substantially faster to complete than a properly designed solution on the RDBMS side - at least not until you are talking tens or hundreds of billions of records on 100+ CPU clusters (this is the linear scalability advantage).

          • by microbox (704317)
            You may be right, but his argument is not without merit. I have seen some SQL queries grow out of control, and they are quite difficult to understand. From a maintenance point of view, this is a disaster. SQL was created to make things simpler -- but like all "next-generation" technologies, it is only simpler for simple cases.
        • by sapgau (413511)

          You are comparing a query from a transactional system vs. a dimensional one.

          To achieve this you have to extract your transactional data and build the cubes needed for the query. Yes it will take a few hours every night to build the cube but your dimensional queries will be fast, efficient and wont bog down the transactional databases.

      • by shic (309152)

        I must take issue with the claim that "The only people who hate on SQL are the people who don't understand databases."

        I think you should take some time and read the extensive publications of Chris Date [wikipedia.org] (of Codd and Date International [codd-date.net] fame) - which, without exception, are extremely critical of SQL (while praising the relational model.)

        SQL has its place - but it is far from perfect... and, the 'shackle of compatibility' prevents most of what is counter-productive about SQL from being fixed. NOSQL, while an i

      • Not only does SQL work, it is the best at what it does.

        The only people who hate on SQL are the people who don't understand databases. Generally, these are the same people who like labels, tag clouds and ruby on rails. They produce a lot of high level hand waving with regards to the actual code and endless amounts of "herp derp I dunno" when asked why their shit performs slower than the 10 year old system it's supposed to replace. These are bad people.

        Here here. Well said. If you think you can do everything without structured data you've never heard of accurate reporting before, which is what businesses need to be competitive and not waste money and all that fancy schmancy business stuff.

    • by garyebickford (222422) <gar37bic@@@gmail...com> on Thursday April 07, 2011 @06:12PM (#35751050)

      Actually COBOL predates SQL by about 10 years. AFAIK nobody has written a language that implements the relational query model to replace SQL. And (though I have never written anything in COBOL he says thankfully) COBOL has its place even today. I would not be surprised if there are as many lines of COBOL still running in enterprises everywhere as there are of PHP or Perl in those same enterprises.

      And COBOL even now is without question a better solution for business and application programming than C ever was or ever will be. (Of course it's arguable that there are other languages better for those tasks than COBOL as well.) C is good for device drivers, kernels and as a target for interpreted and scripting languages with compiled code generators. C is, as Kernighan, Ritchie or Thompson (I forget which) said, "a structured PDP-11 Macro-assembler". Today (putting my Nomex suit on...) IMHO application programmers should not be wasting their time coping with segfaults and compile-link cycles. Their time is worth more than the machine time that any cycle-saving difference. :)

      • by Jonner (189691) on Thursday April 07, 2011 @07:19PM (#35751648)

        Neither SQL nor its original incarnation SEQUEL was the first language based on the relational data model. There are also more recent relational languages, such as Tutorial D [wikipedia.org], though none has gained much popularity and few people know they exist, even in the database management world. We badly need a replacement for SQL that is more flexible and more fully implements the relational model.

      • by microbox (704317)
        Relational algebra [wikipedia.org] is far simpler than SQL for anything moderately complex. The theory and maths are well developed, but there are no implementations. SQL is loosely based on relational algebra, but the "lets-make-this-real-simple" mentality has had the reverse effect. Relational algebra is actually far easier to learn, and becomes expressive like a regular computer language.
      • by smash (1351)

        Their time is worth more than the machine time that any cycle-saving difference

        Be careful with that. If you're dealing with several hundred thousand or million users, then a minute of processing here or there adds up pretty bloody quickly.

    • by O(+inf) (2033618)
      What's wrong with the way (ANSI) JOIN works? It's practically right out of relational algebra. As an aside, the term "NoSQL" has very little to do with SQL-as-language, and really is about relational vs other. Some "NoSQL" solutions provide SQL as a query language for their datasets, and there are some relational databases out there that don't use SQL as a query language, but would not count as "NoSQL".
      • Joke time ! (Score:5, Funny)

        by alex67500 (1609333) on Thursday April 07, 2011 @06:47PM (#35751388)

        An SQL statement walks into a bar. He sees 2 tables and asks "May I join you?"

        • by Compaqt (1758360)

          Naturally, of course.

        • by youn (1516637)

          Lol, this is hilarious... I guess we could let the joke go on... .. and that triggers an angry rant from one of the table that says, ah drop it, had a bad day, I have been out in the field for a transaction that went wrong... I guess I hade been out too long wasn't updated on how corrupt they had become... I had no backup plan, so I think I am out of order

    • Agreed. I've always called it Semi-Quasi-Language.
    • ...is that SQL sucks as a language. It's not terribly expressive, the ordering of arguments is inconsistent, and whoever designed the way JOIN works should be in jail.

      Frankly, I'd like to see SQL die and get replaced with something more modern. We don't program in Cobol anymore, so why the hell are we still using SQL?

      You should not seek to replace something just because it is 'old' and not 'modern'. I've seen quite a bit of the modern SQL-alternatives. They have their niches but I have yet to see one that is ready to topple a well-designed relational database in performance and scalability.

    • The people who think that SQL sucks don't usually understand it. The first hurdle is that you need to think about it as a set-oriented language. You are dealing with operations that work on sets. You select a subset of all objects in the table, filter for only the columns that you want, modify them via update, insert new items, join two sets together, etc. If you come looking at it as a procedural replacement, you are starting out screwed.

      Next, like all languages, the pure relational model has grown wart

      • by Jonner (189691)

        Just because the relational model SQL is supposed to implement is great doesn't mean we don't need a better replacement for SQL. There are alternatives, but they're so obscure, immature, or incompatible with other commonly used tools that hardly anyone ever considers them.

        I use PostgreSQL at work and I'm constantly expanding what I can do with SQL, both as a result of learning and new features that are being added. However, I constantly run into its limitations and extreme ugliness. Even though I work with

      • by microbox (704317)
        The people who think that SQL sucks don't usually understand it.

        My experience, is that the people who designed SQL didn't understand Relational Algebra [wikipedia.org], and made a mess of things. Too bad.
    • by DeadDecoy (877617)
      I've been working with mongo noSQL for a little while now, and it's nice because it's fast and you don't have to de-normalize data that should not have been normalized in the first place. E.g. article{ title, authors, keywords } instead of having a separate table for authors and keywords. This probably attributes to the faster speeds in those databases too. It's not so much that SQL sucks or JOINs are evil, rather that they fit a different use case very well. The argument is somewhat similar to: why should
      • by emt377 (610337)

        I've been working with mongo noSQL for a little while now, and it's nice because it's fast and you don't have to de-normalize data that should not have been normalized in the first place.

        I totally agree with this. MongoBD is great, but so are RDBMS. They serve different functions. The problem I have is with SQL. It's a language, not a data model or representation. In addition, the server sits at the end of a socket and acts like it's an interactive terminal session, using a human-friendly language, one command at a time. This means for instance that the server has to perform queries in the order issued on any one connection, but there is no guaranteed order or way to state dependencie

      • I'm thinking about wading into the noSQL waters. Help me out:

        If authors aren't normalized, does that basically mean you don't have a separate datastore (table, whatever) for authors? E.g., a publisher might want to keep track of author name, address, etc.

        Here's another classic example: country codes vs. country names: (ca, Canada), (us, United States).

        If you want to be able to use both, you'd would (classicly) store "ca" in your User table (for what country he lives in), and then have a separate Countries

    • by Jonner (189691) on Thursday April 07, 2011 @07:06PM (#35751536)

      SQL definitely sucks as a language. However, the relational model it was intended to expose does not. We need languages that more fully and naturally expose the relational model.

    • by sapgau (413511)

      Will a noSQL offer the same SQL properties of transactional databases, with referential integrity, transactions, joins, etc.?

      If so, then it sounds like people just want to change the syntax of how to express sql statements. This will end up into having two query languages which should do the same thing.

    • by codepunk (167897)

      Actually I have no problem with the SQL language. I work in a heavy NoSql environment. We do not hate sql engines it is just that none of them are fast enough to deal with the transaction rates we require.

    • Insightful? People like noSQL because it allows them to have messy unstructured data and not do any data modelling.

      We're still using SQL 20 years later because it's a great layer between your OO code and your relational data. Unless you want to use a heirachical database (which no-one does) SQL works fine. Sure you can use an ORM but at some stage you'll need to handle the conversion between relational and OO.. unless you're happy being ignorant as to how your database works and not be able to performanc
      • Insightful? People like noSQL because it allows them to have messy unstructured data and not do any data modelling.

        In noSQL environments you have to do MORE data modeling than in a traditional SQL DB.

        The data usually is not unstructured at all. Prime examples are Blogs, Forums, Postings, Answers to that postings, Tags, Labels, Users, Priviledges for that Users to see certain, "parts" of the Forums / Postings / Threads etc etc.

        Simple do do with SQL, yes. But not if you have to deal with a million of "posting

    • by Compaqt (1758360)

      One thing that annoys me is the disjunction between UPDATE and INSERT queries for the same set of fields:

      INSERT INTO blah(uid, name, email) VALUES(12,'Goober','goob@example.com')

      But if you want to change that to an UPDATE query, you have to move each of the fields around:
      UPDATE blah SET uid=12, name='Goober', email='goob@example.com'

      This would have been better:
      UPDATE blah SET (uid, name, email) VALUES(12,'Goober','goob@example.com')

      By the way, if you want to read hard-core fundamentalist, pro-relational stu

    • by smash (1351)

      We don't program in Cobol anymore, so why the hell are we still using SQL?

      Because there is plenty of mission critical software built on top of it. Just like COBOL - although toy programmers may not program in it any more, there are decades of business logic written in it, in use by BIG BUSINESS that see no good reason to re-write in something else and re-debug, etc.

      SQL is a "known entity". Introduction of some competing non-standard is going to have an extremely difficult time getting traction unless i

  • by Hazel Bergeron (2015538) on Thursday April 07, 2011 @06:08PM (#35751014) Journal

    Nothing new in computer engineering since 1980. Prove me wrong.

    • by ArsonSmith (13997)

      let's see. 1980 had both 1's and 0's. today we have just 1's and 0's. Even before 1980 someone invented -1's 0's and 1's, but it never really took off.

      So...

      nope, nothing new in computer engineering.

    • by lennier (44736)

      Come on, didn't the Sinclair QL [wikipedia.org] single-handedly revolutionise computing? Aren't we all using stringy floppies [wikipedia.org] today, as we whizz on our C5s [wikipedia.org] to the Ministry of Space [wikipedia.org]?

      In your heart, you know it to be true.

  • "Relational SQL and key-value NoSQL models are mathematically dual, and provides a monadic query language for what they have coined coSQL."

    I'm glad somebody clarified that! (Time to RTFA.)
    • What this all means is that coSQL and SQL are not in conflict, like good and evil. Instead they are two opposites that coexist in harmony and can transmute into each other like yin and yang. Because of the common query language based on monads, both can be implemented using the same principles.

      here, you should have skipped to the conclusion.

    • by Sarten-X (1102295)

      They're wandering doppelgängers... that's obvious, right?

  • If I am running a NoSql solution it is because I need every bit of speed I can muster. Putting a additional layer on top of that does nothing to reach that goal.

    • by Jonner (189691)

      You're not getting every bit of speed you can muster unless you're in control of what's happening at every level, down to every CPU register, byte in RAM, on a disk (not file), and every cache in between. That approach used to be common when chips were slow and expensive, but not any more because it's just not worth the effort. If you're using a "NoSql solution," you are not in control of every byte at every level.

  • I thought the whole reason why NoSQL is "better" than SQL is it's based on column based storage, while most SQL databased are row based storage. Couldn't you make a column-based database that uses SQL as a query language? There is nothing wrong with SQL as a language, there are just some workloads where column based storage is faster (mostly data analytics).
    • Couldn't you make a column-based database that uses SQL as a query language?

      Sybase IQ [wikipedia.org] is column based and uses SQL [sybase.com].

    • by FlyingGuy (989135)

      Column based storage is crutch for idiot MBA's and finance weenies who only understand spreadsheets.

      Just look at their spreadsheets with columns that have 01,02,0n after the names.

      You

      constantly have to tell them that spreadsheet != database.

  • by bigsexyjoe (581721) on Thursday April 07, 2011 @07:42PM (#35751878)

    My I'm just being a nit-picky coder here, but I don't get why they call it noSQL, when they are really referring moving away from relational databases?

    When I first heard of "NoSQL", I thought, "Great! SQL is a terrible syntax with all it's six letter words and easy dangerous mistakes. I would love to have a superior syntax for interacting with the relational databases that are central to my work!" But "NoSQL" should be called "NoRelational." It is kind of strange that you are changing the whole paradigm of the database around and you are describing it as changing a superficial feature. It would be like calling emails "no pen" writing.

  • For people who have worked with NoSQL (assuming you've worked extensively with SQL before):

    1. For someone wanting to either scratch an itch, or come up with the Next Great Thing, would you recommend NoSQL-type solutions to do the standard save data coming in over the web, and later retrieve it, possibly rejigger and summarize it, and feed it back over the web when a user needs it thing?

    2. Is NoSQL generally considered faster than SQL equivalents? At runtime or development time?

    3. Is there a concept of DB de

    • Well,

      I answer slightly simplified, as someone will add his own views anyway ;D

      First of all "NoSQL" does not mean "no SQL" ... it means "not only SQL". In other words, you likely will store parts fo your data in SQL and parts in "no SQL" databases.

      To your questions.


      For people who have worked with NoSQL (assuming you've worked extensively with SQL before):
      The correct word is "intensively" not "extensively" I have no clue why people use that word the last few years everywhere. Extensive is the opposite of int

  • From what I have learned about the uses for and abilities of NoSQL, its a compromise you make when affordable scalability is required to stay in business. It is nowhere near as powerful as the RDBMS/SQL combination, however it is much cheaper to run. Don't believe anyone who tries to tell you there are things you can do with NoSQL that you can't do with SQL. That is complete bunk. Maybe it makes speed cheaper, and scaling easier, but those decisions should be forced by application demand and budget constrai
    • by thaig (415462)

      Well you can create giant planet-sized data stores and find things in them :-) That's pretty cool.

      It seems to me analagous to arguing that neural networks are inaccurate and "nowhere near as powerful as computers". Some 6 billion neural nets out there are nodding along in interest while someone demonstrates their X million line program to algorithmically teach a robot arm to play table tennis in a special room.

  • by bigstrat2003 (1058574) on Friday April 08, 2011 @12:27AM (#35753770)
    Why? MongoDB is web scale, we don't need anything else!
  • Reading the introduction is kind of bizarre. Apparently the motivation for the work is to reduce the NoSQL market to a few very profitable suppliers.

Saliva causes cancer, but only if swallowed in small amounts over a long period of time. -- George Carlin

Working...