Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming

SQL Vs. NoSQL: Which Is Better? 306

Posted by samzenpus from the pick-a-side dept.
Nerval's Lobster writes "For the past 40-some years, relational databases have ruled the data world. Relational models first appeared in the early 1970s thanks to the research of computer science pioneers such as E.F. Codd. Early versions of SQL-like languages were also developed in the early 70s, with modern SQL appearing in the late 1970s, and becoming popular by the mid-1980s. For the past couple of years, the Internets have been filled with heated arguments regarding SQL vs NoSQL. But is the fight even legitimate? NoSQL databases have grown up a bit (and some, such as Google's BigTable, are now mature) and prove themselves worthy. And yet the fight continues. Tech writer (and programmer) Jeff Cogswell examines both sides from a programming perspective."
This discussion has been archived. No new comments can be posted.

SQL Vs. NoSQL: Which Is Better? More

SQL Vs. NoSQL: Which Is Better?

Comments Filter:

  • Flamebait in Headline (Score:5, Insightful)

    by Fwipp ( 1473271 ) on Monday July 16, 2012 @12:31PM (#40663789)

    SQL and NoSQL are different, with different use cases.

    • Re:Flamebait in Headline (Score:5, Funny)

      by medv4380 ( 1604309 ) on Monday July 16, 2012 @12:38PM (#40663845)
      Actually the headline is a typical news headline stated as a questions. So the answer is always no.

      • Re:Flamebait in Headline (Score:5, Insightful)

        by Jeremiah Cornelius ( 137 ) on Monday July 16, 2012 @12:40PM (#40663877) Homepage Journal

        "Hammer or Shovel! Only one of these will leave the room as the single, ULTIMATE TOOL!"

        I believe, in such cases, that the answer is always "The Ohio Players".

        • Re:Flamebait in Headline (Score:4, Insightful)

          by LordLucless ( 582312 ) on Monday July 16, 2012 @05:57PM (#40667009)

          In that case, I think the answer to "what is the greatest tool?" would be "the person asking the question".

      • Betteridge’s Law of Headlines: http://en.wikipedia.org/wiki/Betteridge's_Law_of_Headlines [wikipedia.org]

    • Re:Flamebait in Headline (Score:4, Insightful)

      by s.petry ( 762400 ) on Monday July 16, 2012 @12:42PM (#40663915)

      Exactly! As with all technology each has a purpose. I remember the old days when all we had was binary databases, the reason for the SQL was that the binary blobs could not do everything needed. While I find it interesting that we have seen a lot of growth in the older technology, it is not something new. SQL won't be going away, just like NoSQL never really went away (it just saw negative to no growth for a very long time).

      Remove the bias and fan boy status and what do you have? You have 2 technologies to choose from which can get the job done regardless of your use case.

    • Re:Flamebait in Headline (Score:5, Funny)

      by Anonymous Coward on Monday July 16, 2012 @12:47PM (#40663963)

      SQL and NoSQL are different, with different use cases.

      No. Wrong. Clearly, $CHOICE is superior in all cases. If you think you've found a situation in which !($CHOICE) is better, you're obviously using $CHOICE wrong and should RTFM before you EVER say anything against it again, n00b.

      • Re:Flamebait in Headline (Score:5, Funny)

        by VGPowerlord ( 621254 ) on Monday July 16, 2012 @01:58PM (#40664779)

        SQL and NoSQL are different, with different use cases.

        No. Wrong. Clearly, $CHOICE is superior in all cases. If you think you've found a situation in which !($CHOICE) is better, you're obviously using $CHOICE wrong and should RTFM before you EVER say anything against it again, n00b.

        Ah, but then you have to look at the implications of $UNRELATED_PROBLEM. After all, $CHOICE can't $BUZZWORD1, at least not without support for $BUZZWORD2.

        Once $CHOICE supports those, then maybe it'll be better in all cases.

    • Re:Flamebait in Headline (Score:5, Insightful)

      by Eponymous Hero ( 2090636 ) on Monday July 16, 2012 @12:57PM (#40664079)
      agreed. even the summary is nothing but provocation.

      NoSQL databases have grown up a bit (and some, such as Google's BigTable, are now mature) and prove themselves worthy. And yet the fight continues

      too bad the ones perpetuating the fight haven't grown up.

      Tech writer (and programmer) Jeff Cogswell examines both sides from a programming perspective.

      no thanks. how about we just talk rationally about scenarios in which you would prefer to use one or the other? how about speaking intelligently about the benefits of both, and how they should be properly used, instead of giving any attention to the bickering that is only going on by people who don't know how to use either one properly?

      check out this gem FTA:

      2. Relational data doesn’t map well to typical programming structures that often consist of complex data types or hierarchical data. Data such as XML is especially difficult because of its hierarchical nature. Complex objects that contain objects and lists inside of them do not always map directly to a single row in a single table.

      you mean the developer actually has to do his job? the developer actually has to tell his ORM what he's thinking, and organize his objects in a way that makes the data well understood? shudder to think. "i thought it was all drag and drop in visual studio, i never became a programmer to WRITE CODE!!! omg!!"

      but wait, here's #3 in their list:

      3. Relational data doesn’t map well. Combine that with the need to handle the syntax of SQL, and writing client code for accessing SQL databases becomes difficult.

      look, it's just #2 written a different way. why should i care what incompetent programmers and dbas think about nosql? i eat their breakfast for lunch everyday.

      • Re:Flamebait in Headline (Score:5, Funny)

        by Dragonslicer ( 991472 ) on Monday July 16, 2012 @03:15PM (#40665591)

        Complex objects that contain objects and lists inside of them do not always map directly to a single row in a single table.

        This is so true. If only relational databases had a way to connect a row in one table to a row in another table. It would be even more awesome if it could connect a row in one table to more than one row in another table. Just imagine if you could, I dunno, like, join the data together or something.

    • Re:Flamebait in Headline (Score:4, Interesting)

      by GuldKalle ( 1065310 ) on Monday July 16, 2012 @01:04PM (#40664127)

      The name noSQL itself is flamebait.
      But yes, a much more informative article would br: SQL or NoSQL - when to use what.

      • Re: (Score:3)

        by curunir ( 98273 ) *

        The name noSQL itself is flamebait.

        It's also incredibly misleading. If they'd named it correctly, it would be NoACID. That's the real issue at hand...making a different CAP compromise. The programming interface is really not that big of an issue. Yes, it's different, but as programmers we should be able to adapt to both fairly easily. What really is important is how to achieve high scalability. People have rightly zeroed in on the fact that if your application can tolerate eventual consistency, that problem can get a lot easier than the ACID

  • Well, at least not better overall. Each solution may be more suited to solving a particular problem. You can also use both, or neither!

    • Re: (Score:2)

      by micheas ( 231635 )

      You mean like using lucene and mysql for a website? I haven't done that since ... oh wait I did that for the last four websites I've done.

      Lucene's MLT query is really useful. I woudn't want use Lucene for storing authentication hashes though.

      The question is not which is better, the question is when should you use each of them.

  • "No" (Score:5, Informative)

    by Anonymous Coward on Monday July 16, 2012 @12:33PM (#40663799)

    "No" [wikipedia.org].

  • Stupid question (Score:5, Insightful)

    by adturner ( 6453 ) on Monday July 16, 2012 @12:37PM (#40663839) Homepage

    Might as well just ask: Which is better a BMW M3 or Ford F350 4x4 with 6.7 diesel?

    Both are great, have their place and will get you from point A to B, but neither are a practical replacement for the other.

    My current programming project is a mixture of Cassandra and Oracle (although, to be honest, I'd rather be using PostgreSQL or even MySQL).

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      Might as well just ask: Which is better a BMW M3 or Ford F350 4x4 with 6.7 diesel?

      Both are great, have their place and will get you from point A to B, but neither are a practical replacement for the other.

      My current programming project is a mixture of Cassandra and Oracle (although, to be honest, I'd rather be using PostgreSQL or even MySQL).

      ^ This.

      I am the architect of a NoSQL solution based on Hadoop (and some of its other related projects). The value Hadoop adds to our organization is undeniable ... but so are the traditional RDBMS where we store distilled information from our Hadoop cluster.

    • One question that I've always had: Why do people still use Oracle or other big name, expensive RDBMS when there are open-source offerings as complete as PostgreSQL? Is it a matter of organizational momentum?

      • Re:Stupid question (Score:4, Informative)

        by lambent ( 234167 ) on Monday July 16, 2012 @01:19PM (#40664295)

        Ability to tune for performance on know hardware; better permissions structures; ability to get support from the company; data security, replication, backup; clustering; not wanting to reinvent the wheel using man-hours when you can more easily pay for a known working solution that is well documented ...

        etc. There are a lot of reasons.

        • Ability to tune for performance on know hardware

          That means you don't know the hardware you buy for other companies, only from Oracle?

          better permissions structures

          Yes and no. In some ways the permission structure of Postgres is more versatile than Oracle's. In other ways it's not. The differences between the big DBMS are getting less and less relevant each day.

          ability to get support from the company

          As oposed to the ability to get support from hundreds of companies, all with the same level of access to Postgr

      • Re: (Score:2, Interesting)

        by ebunga ( 95613 )

        Commercial offerings give you someone to sue when things go bad.

        • Re: (Score:3)

          by rtaylor ( 70602 )

          Have you ever tried suing Oracle?

          It might give you a target but you've not going to extract anything from them except perhaps 3 months credit on the licensing costs.

      • Re: (Score:2)

        by adturner ( 6453 )

        In my case, kicking and screaming. Our IT dept uses Oracle extensively for various things and for various reasons that basically forced my team to also use Oracle although we'd all prefer PG or yes even MySQL. Now that my team is moving to JRuby (which is awesome btw), Oracle driver suckage is less of a problem, but we all find Oracle a PITA to use query wise and it's not nearly as well supported in the OSS community for things like ActiveRecord (although recent versions of the oracle_enhanced-adapter see

        • That said, little things like having to use WHERE ROWNUM = X, rather then LIMIT which basically always requires a subselect to get correct results is just annoying and makes our code less portable.

          One of the sad parts of SQL is that row limiting (to my knowledge) isn't part of the standard. So, unless a database explicitly adds support for another database's syntax it doesn't happen.

          For example, from the MySQL docs [mysql.com]:

          For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax.

          Until MySQL 4, MySQL's LIMIT command was LIMIT x,y which was the equivalent of Postgres's LIMIT y OFFSET x.

      • Re: (Score:2)

        by jbolden ( 176878 )

        They aren't complete if you want advanced features. Just to give you a list of major stuff that's missing:

        http://www.oracle.com/technetwork/articles/grid/index-099021.html [oracle.com]

      • Re:Stupid question (Score:5, Insightful)

        by The Dancing Panda ( 1321121 ) on Monday July 16, 2012 @01:48PM (#40664637)
        Not necessarily. MSSQL and Oracle come out as legitimately faster in many use cases. MSSQL is generally easier to set up and use in a small to midsized application than most other offerings, and the code written to use the database can be easily migrated from SQL Express all the way to MSSQL enterprise. MySQL is great, but has been shown to not perform as well on giant data sets. Oracle usually wins in those cases, but it is a BITCH to configure. MSSQL also supports a lot of different data types natively.

        The Open Source solutions are great for a small project, but from many DBAs I've spoken to, don't scale well.

        I should note that I use MySQL on all my home projects. It works wonders. But I wouldn't choose it if I was looking to do something that requires blazing fast query speeds. MS and Oracle have some good products here, despite Oracle not being able to design a user interface to save their lives. MS is good because they bought it, but the Management Studio is quite nice to work in (MS is very good at making developer tools).

        • Re: (Score:2)

          by Twinbee ( 767046 )
          Are MS and Oracle faster than MySQL because they add much more code to solve the problem (e.g.: where all special cases are met), or because they use more clever and efficient code compared to MySQL?

      • Re: (Score:2)

        by s.petry ( 762400 )

        IT people like it better honestly, as well as management types. The logic is of course very different for why each likes said products.

        IT people like it for the support. Expensive, but when bad things happen we have a fall guy and someone to solve problems we simply can not (code changes, etc...). It tends to also have more features than any "Free" product. The "Oh Shit" button is invaluable for more reasons than this mind you. It also means we have to keep buying hardware to meet current versions, etc.

    • Ford mustang of course

    • Besides QtJsonDb will beat them all! In a completely different game..

  • MySQL vs MongoDB (Score:5, Funny)

    by djbckr ( 673156 ) on Monday July 16, 2012 @12:39PM (#40663873)
    I'm sure many of you reading this have seen this, but it's still funny anyway... http://www.youtube.com/watch?v=b2F-DItXtZs [youtube.com]

  • No.

    Isn't there some rule about headlines ending with a question mark can be answered as no?

    Anyway obviously the answer is NoSQL because it's webscale and cloud.

  • Dumb question (Score:5, Insightful)

    by dissy ( 172727 ) on Monday July 16, 2012 @12:40PM (#40663879)

    Replace "SQL" with "hammer" and replace "NoSQL" with "Screw Driver" and then ask the question again. You will see how silly it actually is.

    The right tool is best for the particular job at hand, always. If you refuse to define the job, it is not possible to guess ahead of time which tool will be better for it.

    • Re:Dumb question (Score:4, Insightful)

      by steelfood ( 895457 ) on Monday July 16, 2012 @01:21PM (#40664321)

      You don't even have to leave computer science for an analogy. Is a hash map better than an array?

      That's effectively the question. Those who cannot answer this question have no business writing code.

      • Of course a hashmap is better, you just use a 0 (or 1 if you're using VB) based integer as the key. That way if things change you can reuse your code!

    • unfortunately, there's a lot of people who seem to want to say "use the best tool" and then try to make everything work in a single language (most commonly Java and .NET programmers).

      I see this with the introduction of ORMs - its like programmers don;t want to learn SQL (the tool of choice when using databases) and instead want to make the DB look like a collection of objects. The NoSQL proponents seems also to make the same mistake - that NoSQL is somehow better because you access the data using an API tha

      • unfortunately, there's a lot of people who seem to want to say "use the best tool" and then try to make everything work in a single language (most commonly Java and .NET programmers).

        I see this with the introduction of ORMs - its like programmers don;t want to learn SQL (the tool of choice when using databases) and instead want to make the DB look like a collection of objects. The NoSQL proponents seems also to make the same mistake - that NoSQL is somehow better because you access the data using an API that is native to your language.

        Its a sad indictment of the modern programming community (well, those lesser programmers at least), but I think this is the main driving force behind it all. Blame the holy wars for all this, otherwise we'd be (correctly) talking about NoSQL as just another data storage technology along with relational databases and flat files that has specific use cases.

        I have quite the background in database development, tuning, and pretty much everything to do with DBA work minus the backups, but I love ORMs. Most ORMs these days produce quite good SQL, and they reduce development time dramatically -- especially if you model your DB from your data classes instead of vice versa. Is there a performance hit? Maybe -- you'd be surprised how often the ORM spits out better code than an experienced SQL developer. If there is a performance deficit, you can take care of that m

  • Focusing the "which one is better" on how you query both from a few programming language is like comparing computers by the keyboards attached to them. For small enough workloads (i.e. text processing) maybe would matter how comforable is the keyboard used, but for heavy loads what weights is the engine behind, and how well is adapted to the thing it have to process.

  • The answer to all "Which is better" questions... (Score:5, Insightful)

    by Jason Levine ( 196982 ) on Monday July 16, 2012 @12:42PM (#40663919) Homepage

    Here's the answer to pretty much every "Which is better" question:

    - Option 1 is better in cases where option 1 provides more advantages and less disadvantages than Option 2.

    - Option 2 is better in cases where option 2 provides more advantages and less disadvantages than Option 1.

    - In cases where neither Option 1 nor Option 2 provide a clear advantage/disadvantage distinction, neither is better and either may be used depending on preference.

    Rarely is the answer ever "X is better than Y in all possible cases."

    • Wow. I'm really impressed with the maturity in all of these comments. Now if only other holy wars could be resolved the same way.

  • SQL for Some Projects ... (Score:5, Funny)

    by eldavojohn ( 898314 ) * <eldavojohn@noSpAM.gmail.com> on Monday July 16, 2012 @12:47PM (#40663973) Journal
    Kang: SQL for all.
    *crowd boos*
    Kang: Very well, NoSQL for anyone.
    *crowd boos*
    Kang: Hmm... SQL for some projects, miniature NoSQL implementations for others.
    *crowd cheers*

    • Re: (Score:3)

      by arth1 ( 260657 )

      SQL for some projects, miniature NoSQL implementations for others.

      That's the problem - pretty much every NoSQL implementation that calls itself NoSQL are heavy java apps.

      My rules of thumb:
      - Don't put a database to do a hash table's job.
      - If the reason for the database is that maybe, in the future, someone might want queries run against the data, store the data raw now, and put it in a database then.
      - If you have everything in X, and X will do, don't change it for the reason of changing it.

  • Despite the rather inflammatory name, NoSQL is a complement to SQL, not a replacement for it. They do good jobs at very different things, and should be used for the appropriate tasks.

    The problem comes when someone from either side attempts to do something with his or her chosen side that the other side really is better suited for. Currently the NoSQL folks seem to have a stronger tendency to do this, but that's a problem with the culture, not the tools.

    • Currently the NoSQL folks seem to have a stronger tendency to do this, but that's a problem with the culture, not the tools.

      I think it has more to do with inexperience than culture. The inexperienced tend to gravitate to the shiny hammer and look at all the problems as nails. The experienced have the skill set to pick the right tool for the job.

      New tools tend to attract more inexperienced developers since they haven't developed much of a preference and seem to be the most affected by hype. This ultimately

  • an Oracle DBAs perspective (Score:5, Interesting)

    by Anonymous Coward on Monday July 16, 2012 @12:59PM (#40664093)

    For generic applications that do not have a vast amount of user volume or data set size, NoSQL or any SQL Generator is fine. It is also fine for most of the standard and generic go down a primary key query or do a simple join. However, the more complex queries on larger systems need reviewing. The biggest problem with NoSQL is developers just don't want to be bothered and expect their procedural logic to automatically run in a 20 terabyte database that gets over a million hits a minute. This is the higher end for systems I work on, but it also happens in smaller ones.

    We get by far the worst SQL submitted to us by developers who generate SQL and in general don't know anything. Large Databases rarely stay extremely well normalized. There are rarely data architects around to enforce this. Developers who are in a hurry to meet deadlines denormalize and just add columns. When you do this, over time your sql gets more complex and query generators are not very good.

    Query generators can generate alot of basic sql, but as time goes on requirements get more complex. Developers are building on what other developers did before them. A lot of this data is not normalized and have ridiculously complex logic. We generally get emails from developer going 'this query is slow' and that is it. Or we get I did a query just like this before, but this one is slow. The query generator may be making queries on the fly. So they think its the same thing, but its actually different.

    One other thing that often happens that people overlook is that these tools generate too much SQL. Instead of getting data in 1 sql statement and have a normalized set of tables, I have clicked a button and run 15 sqls serially. When you get alot of traffic, the round trips and the CPU increase adds up. Developers don't know this is happening because it is all done behind the scenes.

    I have had developers with over 10 years experience (some up to 30 years) who can't even figure out the following:

    1. why a query that returns millions of records is slow or can understand the question of 'what the hell is the user going to do with all this?'
    2. why taking fields out of the 'where' clause can affect the query. Dude, cause your no longer using an index.
    3. why running the same query millions of times in a loop would be slow (this is serial). databases are optimized to do stuff in straight sql. Ok this one is not really easy to get at first and it won't be obvious, but if you have done this for 10 years you should have seen it and if I tell you this 5 times and you keep doing it... seriously. This is not that hard.
    4. how different parameters can affect a query. If you run a query that brings back one record, then change the parameters and it has to go through 500 gbs of data your response time will slow down a bit right?
    5. 'it worked in dev'. your Dev DB had tables with 10 records. Prod has 20 terabytes of data. We have told you that prod is much bigger. So you need to atleast check to see if its using an index. This is NOT difficult and I show them how, but they don't care.
    6. your queries are 'slow' because your query generators run 26 queries(serially) when I click this one button. You can combine these to 4 or less and if you pay more attention to the data model and let us making a few simple changes we can get it to 1. However, the 4 i am giving you is fine for now. i can even show them how to audit their sessions activity and how to run a simple query to see what is going on. They click a button and they can see exactly what is happening in the DBA. Most don't care.

    My biggest beef is I tell them what is wrong, I try to explain to them why this is a problem and the vast majority just don't care. They ignore and then do the same thing again. Apparently they don't care that I am subject to 24x7 paging on this stuff and I can't go home if users are complaining, while the developers can go home to their families.

    My other beef is that SQL is not that hard. Its easier than coding. I have been a developer before

    • Re: (Score:3)

      by ahem ( 174666 )

      You shouldn't have posted this anonymously. I think it's great that you've identified the key friction present in all software development efforts: tossing the product over the wall and assuming the downstream person will fix it. Whether it's a product owner tossing incomplete requirements to a developer, a developer tossing code without unit tests or non-performant code to a tester, a tester not validating whether the code will really run in prod, or an operations person blindly deploying whatever comes do

    • Re:an Oracle DBAs perspective (Score:5, Insightful)

      by vlm ( 69642 ) on Monday July 16, 2012 @01:29PM (#40664411)

      Let me put in the "answers" you probably get from noob programmers.
      1) I don't know what a WHERE clause is so I SELECT * and use if statements on each row of the gigs of results
      2) I don't know what a index is
      3) I don't know what a JOIN is so they wrote one in software
      4) ... I donno some workplaces need employee drug testing?
      5) I don't have a real DEV box. Oh I've got a box that endusers can't reach full of non-production code, but I don't have a DEV box that I can test real code on real data. You could simulate a 20 TB prod by provisioning a 2 TB dev on a virtual image of only 1/10th "power", at least for linear scale problems (and the major problems are never linear scale anyway)
      6) I don't know what a GROUP BY is

      I've also done both DBA and code and I can now look back and laugh at my earliest coding. Every noob does stuff like this.

      I have had developers with over 10 years experience (some up to 30 years)

      The world is full, not just devs, but the whole world is full, of people who have 60 "first six months" of experience over and over and over. Some folks just never learn.

    • "My other beef is that SQL is not that hard. Its easier than coding."

      Right. As you said:

      "SQL is just a programming language."

      It's not SQL that can trip a developer up, it's understanding how the RDBMS stores and fetches data, builds indexes and optimizes queries. It's a little like understanding how the compiler will optimize your code, but then it goes even further.

      For example, it would be easy for a developer to be tempted to store a UUID as a primary key in an InnoDB database for a user session table, si

      • Re: (Score:2)

        by rev0lt ( 1950662 )

        a developer to be tempted to store a UUID as a primary key in an InnoDB database

        If you are using a UUID as a primary key on MySQL, is probably because you really need it (unique keys in cluster, ref to external databases, etc). And while it is slower than using a bigint, it's not that slower (you read from disk in 512 or 4096 byte blocks, and that is usually way more expensive than performing a 16-byte compare - so a sequential scan of a bigint and an UUID are probably similar).

        It's also not always clear how to make full use of indexes ...

        That's why there is an EXPLAIN clause in most RDBMs. You can see exactly how the query will be interpreted by

  • Hardware wasn't powerful enough for world domination until the late 1980s. For the 10 years prior to that, network databases and plain old VSAM/ISAM were dominant though slipping.

  • The article is pretty good at doing what it wanted to do. The problem is it's trying to do the wrong thing.

    Its too basic. Its example is of "hello world" caliber. The problem with basing decision on "hello world" scale problems is real world problems don't scale equally in all languages. For example, you can't beat the simplicity and rapid development of "bash" when you want to do a "hello world", and java looks absolutely awful as a "hello world"... However most devs would agree, that in a gigantic zi

  • Wrong person doing analysis (Score:4, Insightful)

    by aristotle-dude ( 626586 ) on Monday July 16, 2012 @01:10PM (#40664199)

    "Tech writer (and programmer) Jeff Cogswell examines both sides from a programming perspective."

    Irrelevant. The data exists to serve the needs of the business and programmers/developers work to serve those needs. The company should chose the best tool for the job which is a usually a relational database as it serve the needs of the "business" the best in most cases. If you are looking to see which is easier for you then you are a shitty programmer and you need to upgrade your skills to understand how to work with relational databases. You should not be dictating what storage methodology is used for the data.

    To be a competent developer, you need to have some understanding of how databases work because you cannot rely on the DBA to babysit all of the projects. You should understand what indexes are, the difference between and inner and outer join and when you can use each time and you should test your code against a large data set to find any bottlenecks on the database side.

    • The data exists to serve the needs of the business and programmers/developers work to serve those needs.

      +1. Every developer should be made to write 100 times on the whiteboard: "The data belongs to the enterprise, not to the application."

      Data architecture is a discipline in itself, not something a developer does off the side of his/her desk.

      --
      .nosig

  • The article seems to confuse three entirely different approaches alternative to SQL.

    1) Modern NoSQL, the product he lists. These are basically an old fashioned Network Databases for UNIX servers. The goal being to get performance much higher than what is possible with Relational at the expense of making the database far less flexible.

    2) Associative Databases. The goal being to drive up flexibility substantially often at the expense of performance, by orders of magnitude.

    3) Object-Relational. The goal

  • ignoring history, are we? (Score:5, Informative)

    by sribe ( 304414 ) on Monday July 16, 2012 @01:15PM (#40664249)

    For the past 40-some years, relational databases have ruled the data world.

    Bullshit.

    In 1972 hierarchical databases ruled the world (with a few network-model attempts here and there) and continued to do so well into the 1980s. In fact, the theory behind relational databases had only been articulated and published in June 1970. In further fact Oracle wasn't founded until 1977, and didn't ship anything until 1979, and they were the first to successfully promote that new-fangled "relational" stuff in a commercial product--prior to that IBM kept it locked up in the lab, except for some very obscure "mostly demo-ware" things, so it wouldn't threaten their then-current cash cow: IMS. IBM's entry into the relational database world, in the early 1980s or so, was a direct response to the growing sales of Oracle.

    Also in the 1980s we got: Sybase, Informix, Ingres, MS SQL Server. Then in the 1990s we started getting open-source RDBMSs, along with actually robust versions for Windows-based servers. Then in the 2000s holy crap we even got good database servers on Macs!

    Anyways, relational databases have really only "ruled the world" for the past 20 some years ;-)

  • Best tool for the job (Score:3)

    by ianare ( 1132971 ) on Monday July 16, 2012 @01:16PM (#40664261)

    As other have said, there isn't one that's "better" than the other in a general sense. However, there are situations in which one is better suited to a task at hand.

    This is of course something that applies to many different aspects of application design and architecture.

    As an example, I'm developing a high volume, high transaction website application and use both PostgreSQL and MongoDB.

    We use SQL where strict relations, type checking, and data integrity are required. The SQL database has the extremely important function of making sure the data given to it by the application is coherent. I realize that MongoDB has functions for checking data integrity, but it is tricker to get right in my opinion and experience (it does allow greater flexibility however). Also, the application has the need for atomic operations and transactions, which MongoDB does not provide.

    MongoDB on the other hand, is used where it delivers better performance than PostgreSQL. For example all our logging is sent there, giving near-disk performance while allowing quick and easy searching and archival. Our session is also handled by MongoDB. Finally we make great use of gridFS for all our uploaded content and document storage. We're also looking into MongoDB for data analysis and reporting, fed data from SQL.

    So there's no reason to pick one over the other, a mix and match approach will yield better results. Where tasks require greater speed and have loose integrity requirements, go for NoSQL. When the data absolutely needs to be coherent and is by its nature relational, go for SQL.

    Also, PostgreSQL will soon support embedding JSON objects directly, so some sort of hybridization is foreseeable in the future. As of now we simply put the Mongo ID in SQL when we need to reference.

  • The issue is people trying to shoe-horn what should be SQL into NoSQL. NoSQL has it's uses, but so many people don't understand why SQL fits better than NoSQL in most situations. There is a reason SQL has been around for a VERY long time and most technologies are still implemented in SQL and not NoSQL.

    Whether it's people just wanting to use the cool new technology and finding out later that what they could do in SQL is just not feasibly possible in NoSQL. Then you and your project are in a serious pickl

  • Look the DBA's are all going to cry that the sky is falling as they have skin in this game.

    At the end of the day though there are some work loads that NoSQL is just a better tool for the job. There are others for instance when you need something acid compliant and relational like a traditional db.

    Anyone that claims you should always use just one or the other is a complete idiot.

  • The No_SQL people are out of their minds. SQL means "structured query language." It is nothing more than a linguistic methodology for accessing data. As we all know, the various databases, MySQL, PostgreSQL, Oracle, MSSQL, couchdb, Cassandra et al are storage platforms with access systems. You need to debate the needs of the storage platform for your application because, make no mistake, just about all the "No SQL" databases pretty much have a top-level SQL language interface available for them.

    "Relational

  • You know ... (Score:3)

    by bhunachchicken ( 834243 ) on Monday July 16, 2012 @01:50PM (#40664663) Homepage

    I've been coding professionally for 11 years, have been hobby coding for about 20.

    Recently, I've been exposed to Agile, Scrum, XP, TTD, User Stories, Sprints, Pair Programming, and now NoSQL. All these things, I have to say, are contributing massively to my strong considerations to hang up my mouse and keyboard.

    My first experience of Agile was working for an investment bank where they decided that, no matter if the code was buggy or was only partly complete, we would push it out to the clients. No problem, our next sprint would fix the bugs. Another project I worked on saw me having to attend hours and hours of meetings, filling out small cards to stick to white boards, listening to people who have no relevance to my project talking about what they were doing, and constantly giving estimates to project managers so that they could make further adjustments to later sprints. When I finally sat down to code that day, it was about 3 lines. I wasn't allowed to work on anything else, because that hadn't been assigned to this sprint. Fun.

    I recently had a telephone interview with a man who spoke to me for 40 minutes straight about agile and did not ask me one single technical question. Nothing on Java, Spring, Hibernate, XML, SQL, or anything else listed on my CV. He even wanted to know whether I used physical note paper or software for details the tasks and user stories. When he asked me two days later if I would like to come in for an interview, I declined. I want to code, not work for a bureaucracy.

    I remember when coding was fun and we didn't have to adopt all these so-called methods. I have no idea what NoSQL is, all I remember is someone at my last contract deciding we were going to use it and then teaching everyone how to query using JSON or Javascript or whatever. It took us a few weeks to get our heads around the idea, and I have to wonder what the benefit of writing Java-JSON-Mongo DB interfaces were over SQL. He did not do this because the project needed it, but because he had heard about the system and wanted to shoe horn it into the project. Seriously, that was the only reason.

    I'm not even sure what Agile is, to be honest. I think it's just some fancy term used by managers to make it sound as if they're being efficient and know what's happening.

    One has to wonder exactly what was wrong with the previous approaches. We all still had working software 6 years ago, from what I remember ...

  • I hope this doesn't come off the wrong way, but where's the god-damned link?

    I'm tagging this as missinglink.

  • You should be asking:
    SQL Vs. NoSQL: Which Is Better For What?

  • It took me a while to figure out that the NEW article, really is buried in a sentence that refers to past arguments.

    This is really poor editing.
    The hyper link should be connected to the (Jeff C says..) phrase instead, or something like that.

  • Hate to disparage /., but have ANY of the topics out of the BI section been insightful?

    Maybe my expectation is that it will get me thinking technically or even business decision making. They haven't. They just make me wish I hadn't spent the 5 minutes (I'm a slow reader...) reading the article and researching if the author is some sort of hack.

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close