Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SQL Vs. NoSQL: Which Is Better?

samzenpus posted more than 2 years ago | from the pick-a-side dept.

Programming 306

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

cancel ×

306 comments

Sorry! There are no comments related to the filter you selected.

Flamebait in Headline (5, Insightful)

Fwipp (1473271) | more than 2 years ago | (#40663789)

SQL and NoSQL are different, with different use cases.

Re:Flamebait in Headline (5, Funny)

medv4380 (1604309) | more than 2 years ago | (#40663845)

Actually the headline is a typical news headline stated as a questions. So the answer is always no.

Re:Flamebait in Headline (4, Insightful)

Jeremiah Cornelius (137) | more than 2 years ago | (#40663877)

"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 (0)

Mike Wag (2683017) | more than 2 years ago | (#40663907)

The heated battle is mostly heated because Google keeps throwing oil into fire. Oracle and Microsoft gladly showed that relational big corporate databases are much faster and better than NoSQL. But Google keeps promoting their own shit because it's their own shit. And it's shit.

Re:Flamebait in Headline (4, Insightful)

gl4ss (559668) | more than 2 years ago | (#40663951)

The heated battle is mostly heated because Google keeps throwing oil into fire. Oracle and Microsoft gladly showed that relational big corporate databases are much faster and better than NoSQL. But Google keeps promoting their own shit because it's their own shit. And it's shit.

that statement makes no sense. just answering the headline with "BABABABA" makes more sense.

maybe if the submitter of the article had included an actual scenario..

Re:Flamebait in Headline (5, Insightful)

Anonymous Coward | more than 2 years ago | (#40664345)

Last I checked, Google is not selling "their own shit" as a product.

I am speaking here as a professional SQL developer with nearly a decade of experience and a very solid knowledge of relational theory. For many of the things we use relational DBs for, they are the best solution. But there are a lot of other applications for which a RDBMS is overkill, and a tool like BigTable is ideal. There are others where a single XML file would be better. There are others where a simple text file would be better.

If people would stop arguing that you have to use a jack-hammer to solve a problem best suited to a ballpeen, we wouldn't have these arguments.

Re:Flamebait in Headline (4, Insightful)

SQLGuru (980662) | more than 2 years ago | (#40664421)

And thus, the answer (as in most cases with technology) is "it depends".

There is no one tool to rule them all. The various languages and technologies were created to solve a specific problem that a different tool or technology didn't quite address well. SQL is great. NoSQL is great. Both have their place. The key is using the right tool for the problem and to quit thinking one is better than the other.

Re:Flamebait in Headline (1)

postbigbang (761081) | more than 2 years ago | (#40664541)

Exactly.

But there's no fun in not writing a Huffington Post-like headline to whore pageviews. Must be a mild Monday.

Re:Flamebait in Headline (0)

Anonymous Coward | more than 2 years ago | (#40664045)

So you are saying that NoSQL is better? :-)

Re:Flamebait in Headline (3, Insightful)

s.petry (762400) | more than 2 years ago | (#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 (5, Funny)

Anonymous Coward | more than 2 years ago | (#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 (1)

cryptographrix (572005) | more than 2 years ago | (#40664025)

Agree - this is total flamebait.

Re:Flamebait in Headline (4, Insightful)

Eponymous Hero (2090636) | more than 2 years ago | (#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 (3, Interesting)

GuldKalle (1065310) | more than 2 years ago | (#40664127)

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

Re:Flamebait in Headline (0)

Anonymous Coward | more than 2 years ago | (#40664185)

Perhaps if more articles were promoted that explained what use cases are mapped to which solution, then we might see far fewer of these articles that advocate one solution for all use cases.

Out of curiosity, is there a canonical document somewhere that does explain the mapping?

One doesn't have to be "better" (1, Insightful)

MetalliQaZ (539913) | more than 2 years ago | (#40663797)

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

"No" (5, Informative)

Anonymous Coward | more than 2 years ago | (#40663799)

"No" [wikipedia.org] .

Re:"No" (-1)

Anonymous Coward | more than 2 years ago | (#40664021)

"No" [wikipedia.org] .

*sigh* Oh, for fuck's sake, some hipster asshole found that someone coined some convenient, soundbite-sized phrase, so now all the we're-definitely-not-sheep! are going to think they're smart and clever by linking to it every other fucking article, aren't they?

Guess I'd better avoid the comments section for a month or so until some new shiny comes by to distract you lot...

Maybe... (0)

Anonymous Coward | more than 2 years ago | (#40664063)

Maybe Slashdot should stop posting shit with ridiculously transparently flamebaity headlines just to generate hits...

Re:"No" (3, Funny)

TeknoHog (164938) | more than 2 years ago | (#40664365)

*sigh* Oh, for fuck's sake, some hipster asshole found that someone coined some convenient, soundbite-sized phrase, so now all the we're-definitely-not-sheep! are going to think they're smart and clever by linking to it every other fucking article, aren't they?

No.

Pretty good article, cheezy headline (0)

Anonymous Coward | more than 2 years ago | (#40663811)

No points for guessing the author's answer to the question posed by the title.

Well (0)

Anonymous Coward | more than 2 years ago | (#40663815)

I use whatever RMS uses, so yeah.

Stupid question (5, Insightful)

adturner (6453) | more than 2 years ago | (#40663839)

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:Stupid question (2, Interesting)

Anonymous Coward | more than 2 years ago | (#40663955)

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.

Re:Stupid question (0)

Anonymous Coward | more than 2 years ago | (#40664089)

MySQL doesn't even honor the "null values are not distinct" in the standard. An SQL that allows 'group by' in a select with more than one column and no aggregate functions is not an SQL to be taken seriously.

Re:Stupid question (2)

Villageidiot9390 (640068) | more than 2 years ago | (#40664091)

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 (0)

Anonymous Coward | more than 2 years ago | (#40664253)

Oracle offers complete turnkey solutions, including the support contracts the PHBs adore so.

Re:Stupid question (4, Informative)

lambent (234167) | more than 2 years ago | (#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.

Re:Stupid question (1, Interesting)

ebunga (95613) | more than 2 years ago | (#40664305)

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

Re:Stupid question (2)

rtaylor (70602) | more than 2 years ago | (#40664563)

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:Stupid question (1)

adturner (6453) | more than 2 years ago | (#40664389)

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 seem to have solved many of our problems), etc.

That said, there have been some things that Oracle does really well and actually makes easy compared to PG/MySQL, but it's been a constant learning exercise for us. 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.

Not to say other RDBMS don't have their own set of problems, but at least we have a few decades worth of combined experience of PG/MySQL so we know how to avoid/work around them. But hey AC, thanks for the troll!

Re:Stupid question (1)

Ryanrule (1657199) | more than 2 years ago | (#40664569)

Ford mustang of course

Easy! (0)

Anonymous Coward | more than 2 years ago | (#40663857)

Which one is web scale?

Which is better? A Bus or a bicycle ? (0)

ralatalo (673742) | more than 2 years ago | (#40663859)

Well, the bicycles uses no Gas, but the Bus can carry 50+ people in a single trip. So which is better?

Re:Which is better? A Bus or a bicycle ? (2)

greg1104 (461138) | more than 2 years ago | (#40663993)

This is very close to providing the car anology I was looking for, but it just misses the bus on that.

Re:Which is better? A Bus or a bicycle ? (1)

shutdown -p now (807394) | more than 2 years ago | (#40664047)

So which is better?

An SUV, duh.

Re:Which is better? A Bus or a bicycle ? (1)

Hatta (162192) | more than 2 years ago | (#40664105)

Why not get the worst of both worlds [pedal-party.com] by combining them?

Re:Which is better? A Bus or a bicycle ? (0)

Anonymous Coward | more than 2 years ago | (#40664225)

doesn't matter. bicycle uses no gas so it wins no mater how many people the bus can carry.

MySQL vs MongoDB (5, Funny)

djbckr (673156) | more than 2 years ago | (#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! (1)

serviscope_minor (664417) | more than 2 years ago | (#40663875)

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.

Re:No! (3, Informative)

greg1104 (461138) | more than 2 years ago | (#40664005)

Betteridge's Law of Headlines [wikipedia.org] is the rule you're looking for.

Re:No! (1)

camperdave (969942) | more than 2 years ago | (#40664297)

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.

Webscale and cloud? What the blaze is webscale, and since when is cloud an adjective?

Dumb question (4, Insightful)

dissy (172727) | more than 2 years ago | (#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 (3, Insightful)

steelfood (895457) | more than 2 years ago | (#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.

Re:Dumb question (1)

oobayly (1056050) | more than 2 years ago | (#40664589)

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!

Re:Dumb question (2)

gbjbaanb (229885) | more than 2 years ago | (#40664423)

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.

NoSQL of course (1)

cheaphomemadeacid (881971) | more than 2 years ago | (#40663881)

SQL is waaaaay too structured!

Re:NoSQL of course (1)

Bigby (659157) | more than 2 years ago | (#40664035)

Because data doesn't need structure...

Comparision criteria? (1)

gmuslera (3436) | more than 2 years ago | (#40663903)

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... (4, Insightful)

Jason Levine (196982) | more than 2 years ago | (#40663919)

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

Re:The answer to all "Which is better" questions.. (0)

Anonymous Coward | more than 2 years ago | (#40664001)

> the answer to pretty much every "Which is better" question

I suggest you check the proper authority on these issues, Mr Harry Hill, who has provided many examples of the correct handling procedure.

http://www.youtube.com/watch?v=8ajHs8tCWew

Hammer versus screwdriver: Which Is Better? (0)

thue (121682) | more than 2 years ago | (#40663923)

nt

A disappointingly misleading headline. (1, Offtopic)

blcss (886739) | more than 2 years ago | (#40663935)

Relational vs nonrelational? It depends on the application. That's so obvious it needn't be discussed.

But I really, really hate SQL AS SUCH. It's an inefficient and overly complex interface that's full of security holes. Now there's a discussion worth having. But noooo...

The question should be "when" not "which" (1)

devforhire (2658537) | more than 2 years ago | (#40663939)

The real question should when should I use a SQL solution and when should I use a NoSQL solution, or more specifically which database should I use for project X. Neither one is better than the other, as each has a specific problem it attempts to solve. As a community we should spend more time discussing what make a technology the best solution for a specific problem-space, not having fan-boy wars.

Oblig Billy Madison (1)

denvergeek (1184943) | more than 2 years ago | (#40663965)

Shampoo is better! I go on first and clean the hair!

How is it (0)

Anonymous Coward | more than 2 years ago | (#40663969)

that slashdot editors still cannot figure out how to select link text that actually corresponds to what is being linked to?

SQL for Some Projects ... (4, Funny)

eldavojohn (898314) | more than 2 years ago | (#40663973)

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:SQL for Some Projects ... (0)

Anonymous Coward | more than 2 years ago | (#40664095)

Don't blame me, I voted for Kodos.

Re:SQL for Some Projects ... (2)

arth1 (260657) | more than 2 years ago | (#40664175)

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.

Re:SQL for Some Projects ... (0)

Anonymous Coward | more than 2 years ago | (#40664383)

Exactly. AKA what the HELL do you think data warehousing is for? So you don't have to run queries against raw data!

Legit question (0)

Anonymous Coward | more than 2 years ago | (#40663987)

This is not a flame bait question, because object oriented databases are relatively new in terms of their adoption and they are gradually replacing instances where once SQL would have been the only option. I've only seen serious adoption of object oriented dbs since around 2000, while SQL has been around, well forever.

The question should perhaps be rephrased: What types of projects lean towards an object oriented database as opposed to a traditional SQL relational db?

For sure there are lots of legacy SQL deployments out there that would be better served in an object db.

Re:Legit question (1)

medcalf (68293) | more than 2 years ago | (#40664121)

Well, LDAP has been around since the 1990s, is object oriented, hierarchical, distributed and segmented. This stuff is not new. NoSQL is interesting, and there are cases where it's both useful and lighter weight than the alternatives, but for most purposes, LDAP would serve just as well. NoSQL does make developers' lives easier, though, because they don't necessarily have to think about their data in advance, which both RDBMS and LDAP systems require. Easier is not necessarily better, but sometimes it is, and many people opt for easier regardless.

Re:Legit question (4, Insightful)

serviscope_minor (664417) | more than 2 years ago | (#40664193)

NoSQL does make developers' lives easier, though, because they don't necessarily have to think about their data in advance,

I've heard claims like these a lot, and I must say that I've never understood them. Programs maniuplate data. I just don't see how you can write a program without knowing about your data. It makes no sense.

Neither. (0)

Anonymous Coward | more than 2 years ago | (#40664007)

If one were "better" than the other, the other wouldn't exist.
Different things work better for different people/infrastructures.
I'd expect a "news for nerds" site to know at least that much.

Re:Neither. (0)

Anonymous Coward | more than 2 years ago | (#40664189)

f one were "better" than the other, the other wouldn't exist.

That argument is nonsense. First, SQL exists for far longer than NoSQL, so when only judging from being available, one possibility would be that NoSQL is better, but simply didn't have the time to replace SQL yet. On the other hand, it could be that SQL is better, but many people fail to recognize that and just follow the newest fad (it is a myth that people always use the best tool for the job). Or, of course, it could be that indeed both have their strengths and weaknesses.

So which is it? Well, you'll not find out without actually looking at them. Both being available just tells you close to nothing (well, it tells you that neither sucks too badly).

One point for NoSql Data bases (-1, Flamebait)

Coeurderoy (717228) | more than 2 years ago | (#40664011)

NoSql Data bases encourages/forces you to think harder about the structure of you data, and the way you'll be using them.
So although you can solve about any DB related problem with either type of database, you will probably end up with a cleaner and easier to understand structure with a NoSql.
Typically Sql developpers tend to throw everything into the data base, then create marvelously large queries, and finally pout when you complain about performance, that "if they had had the time they would have some stored procedures, and the server is too slow anyway...."

On the minus side It is somewhat easier to build complex transactions with most Sql platforms, and somewhat easier to maintain consistency,

But NoSql bases are also in most case very easy to understand for any programmer, not only experienced DBA, and very easy to adapt to situations where you basically want a persistent store.

Re:One point for NoSql Data bases (0)

Anonymous Coward | more than 2 years ago | (#40664129)

I've been using NoSql data bases for a long time now. The one I use now is called ext4. It's great, and even came built into the OS.

Re:One point for NoSql Data bases (0)

Anonymous Coward | more than 2 years ago | (#40664133)

But NoSql bases are also in most case very easy to understand for any programmer, not only experienced DBA, and very easy to adapt to situations where you basically want a persistent store.

If you can understand how to program you can understand how to layout an sql database in a reasonable way for just about anything. This argument that "any" programmer can understand NoSQL but not SQL is flawed, because there is no reason they can't other then being too lazy or unwilling to learn how the datastores that support their applications actually work. In which case they probably aren't a very knowledgeable or good programmer.

Re:One point for NoSql Data bases (2)

zifn4b (1040588) | more than 2 years ago | (#40664143)

Typically Sql developpers tend to throw everything into the data base, then create marvelously large queries, and finally pout when you complain about performance, that "if they had had the time they would have some stored procedures, and the server is too slow anyway...."

This should be marked as flamebait. This is only true of some developers i.e. those who are ignorant about RDBMS. They should make it their business to understand RDBMS especially in large scale applications where performance is critical. This particular aspect alone forces any developer or DBA to have think "hard" about the structure of their data such as transactional vs. analytical needs. If used appropriately, an RDBMS can be quite intuitive and performance/space efficient. It all comes down to understanding the tool you're using. If you don't know how to use a screw driver or a hammer, you probably shouldn't be using it!

Re:One point for NoSql Data bases (1)

vlm (69642) | more than 2 years ago | (#40664257)

Typically Sql developpers tend to throw everything into the data base, then create marvelously large queries

Noobs model their reports and inevitably screw it up when they can't add new reports without changing their data model. When they use 50 JOINs they complain JOIN is slow because they've apparently never heard of indexes.

Intermediate folks model the underlying data, and can support both the current planned queries and any new future queries. When they use 50 JOINs its fast as heck because they know what a JOIN is, but they burn insane quantities of disk space (I remember one deployed piece of network monitoring gear that somehow burned about a meg of disk for every 100 bytes of connection data, but good lord every query was lightning fast)

Pros model both, separating the real-world-model data store from the report store. When they see 50 JOINs they yell at the noob programmers because they specifically created view tables and custom query tables solely so the noob programmers don't have to write 50 JOIN queries.

The answer is "yes". (1)

Millennium (2451) | more than 2 years ago | (#40664041)

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.

Re:The answer is "yes". (2)

Bill_the_Engineer (772575) | more than 2 years ago | (#40664289)

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 leads to the new tool being used in all cases (regardless of suitability) instead of the correct or more appropriate tool.

Notice that I'm not saying that the new tool is inferior, just being misused.

Apples Vs. oranges: Which is better? (0)

seifried (12921) | more than 2 years ago | (#40664065)

Cats vs dogs. Etc.

First rule of headlines (-1)

Anonymous Coward | more than 2 years ago | (#40664081)

If the headline is a question, the answer is no.

SQL vs NoSQL: which is better?
No.

an Oracle DBAs perspective (5, Interesting)

Anonymous Coward | more than 2 years ago | (#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. The big difference is that it uses set based logic and most programming langauges are procedural, so you have to look at it a little differently. This isn't that different. There isn't that much to know. OK, I get it when there are a few REALLY complex queries because the system has changed over the last 5 years and the data model does not fit the new requirement. That should go to a DBA.

SQL is just a programming language. Its not the languages fault you don't understand how it works.

I think the biggest reason why developers don't care is that once its in prod, they have met their deadlines. When it goes to prod, I carry a 24x7 pager and get paged if stuff is slow. I can't go home if your code is slow. Trust me ,developers go crazy when I call them at 2 AM on a Saturday and go 'your query is really slow, users are complaining, get online. If I have to be up, you do too'. They cry to managers. It is always 'I have deadlines', they don't care that 'I have a pager'. They also don't care that most DBAs can tell your managers 'this is not the developers fault, the logic is complex, we have to look at it' and often get your deadlines adjusted without fault going to you.

All this being said, there are some super star developers who get it. They can code SQL, or if I tell them what is wrong, they are actually interested in what I have to say. I often get 'oh no one told me its this easy' quite a bit. These guys don't have the highest IQs, they just seem to have a little common sense and empathy. They are also curious about things outside of their narrow area of expertise.

Re:an Oracle DBAs perspective (2)

ahem (174666) | more than 2 years ago | (#40664373)

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 down the pipe.

All of these non-communicative behaviors work together to create a sub-optimal user experience (and pissing off the people who benefit from the system you build is a self-defeating practice, since they're the ones that indirectly sign your paycheck).

Re:an Oracle DBAs perspective (4, Insightful)

vlm (69642) | more than 2 years ago | (#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.

Re:an Oracle DBAs perspective (2)

garett_spencley (193892) | more than 2 years ago | (#40664499)

"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, since to do otherwise would be adding a redundant ID field, not knowing that InnoDB stores it's rows with the primary key index and thus orders all inserts by primary key.

It's also not always clear how to make full use of indexes ... especially when you need to optimize ORDER BY's (which as you would know can't always be done, and thus need to rely on narrowing the result set as much as possible before the sort), and it's not always obvious how adding a second column in your WHERE or by using aggregates on your indexed columns can make using the index impossible. Those aren't really SQL issues, they're DB issues. Heck, the entire concept of an index has nothing at all to do with SQL (unless you're doing something directly with the index on the schema, but then developers rarely touch the schema when there's a DBA involved) .

You're absolutely right, though, that a competent developer would take the time to learn as much of this as possible. DBAs are in an unfortunate situation because it's tempting for the developer to adopt an attitude of "That's why we have a DBA." I definitely sympathize with you.

Obvious - NoSQL is webscale (1)

unixhero (1276774) | more than 2 years ago | (#40664117)

Re:Obvious - NoSQL is webscale (0)

Anonymous Coward | more than 2 years ago | (#40664291)

Web scale eh? I reckon I can put this on my buzzword bingo card. >_>

In other forums... (0)

pehrs (690959) | more than 2 years ago | (#40664123)

<rant mode>
I had a look in the other forums I frequent, to look around for similar questions. And look what I found:

In the construction forum:
Screwdriver vs Hammer: Which is better?

In the art forum:
Pencil vs Pen: Which is better?

In the transportation forum:
Walk vs Drive: Which is better?

In the pets forum:
Cat vs Dog: Which is better?

In the energy forum:
Wind vs Hydro: Which is better?

And guess what? They all came to the same conclusion. "It depends".

Can we now stop posting "SQL vs NoSQL: Which is better?" stories like this one, as they are utterly pointless?

For the article to be useful the author needs to chose and describe use cases that actually matters to the reader. "Better" is not a use case, and I really hope people don't pick the backend for their application based on how easy it is to implement a few tiny examples in C# or Node.js which is the only thing resembling a use case in that mess of an article.
</rant mode>

SQL ruled for 40 years? ROTFLMAO. (1)

Nutria (679911) | more than 2 years ago | (#40664167)

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.

SQL Vs. NoSQL: Which Is Better? (0)

Anonymous Coward | more than 2 years ago | (#40664173)

Actually it always surprises me that this kind of question comes up. As I understand it from the theoretical side, the point is that if the relational model is correctly implemented, which definitely does require a very detailled analysis of the structure of the data and the way it will be used, then it can be mathematically proven that a properly formulated query will retrieve the full set of tuples in the relation which meet the selection criteria. In applications where this level of certainty is required, then it can be the most important factor.

Is the provability of NoSQL mathematically guaranteed ?

Wrong focus, otherwise good. (1)

vlm (69642) | more than 2 years ago | (#40664191)

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 zillion user system you're probably better off after X zillion lines of code with java than bash. What makes it worse, is one of the main arguments of nosql is its OK to make the devs suffer with an inherently featureless crude tool because its 100 times as fast... which only matters in absolutely huge implementations.

That said, ignoring the incorrect aim, its actually a pretty darn good article that hits all the major points and is reasonably well written.

One point he did miss is that database hardware performance is exploding as is clustering support. We ran multinational companies using "slow" SQL decades ago, and every year sql databases are more capable, but at least my userbase and dataset size is not increasing as quickly. Its the tired old anti-optimization argument from plain old coding, as applied to DBs. So SQL really does limit me to only maybe 100000 times the size I'm currently operating at, and at a conservative DB hardware capability growth rate of 10% per year and a realistic measured long term user growth rate of 0% I'll hit the performance barrier right about ... never. Oh OK then. Well since my inherently relational problem space seems to easily fit the current and future capabilities of relational DBs, I think I'll stick with relational DBs and not waste effort, time, and money wedging that relational problem-space into a non-relational tool. Thats the most important reason not to do nosql.

Wrong person doing analysis (3, Insightful)

aristotle-dude (626586) | more than 2 years ago | (#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.

oracle DBAs response 2 (0)

Anonymous Coward | more than 2 years ago | (#40664235)

This is from the article.

      1. Joins in relational databases can slow the system down to a crawl, especially when millions of users are doing lookups against tables with millions of rows of data. Google and Amazon found this to be the case, and thus developed their own non-relational systems.
e
-- this is about half write. What tends to happen over time is that there isn't alot of control over the data model, so the mapping between tables is weak. Few projects have data architects/modellers on the team and the few that do, don't give them any real authority, or they are not any good. What happens over time is that people are in a hurry to get things done and just add columns and don't think about how the data flows together. This leads to complex joins that do not perform well. I would like to see how NoSQL does over the next 10 years on systems that stick around and are enhanced and grow. I would be very curious.
This issue is not about the SQL, its the DB design. This is from experience and alot of it as both a DBA and a database architect.

From many years of experience, it is not the join in and of itself that is the problem, its the lack of control and organization of the table design over time as logic changes and gets more complex. People just want to add columns and throw stuff out there. I'd really like to see how NoSQL handles this on very large systems that are enhanced over 5-10 year periods.

        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.

-- This is about half right. The only real different in hierarchical modelling from a table layout is all the 1 to 1 designs with redundant data. Normalization is designed to eliminate all the 1 to 1 relationships. It is really not that hard to write queries that handle this for you. When you have inheritance, think about what you are doing, you are making an object with functions and data based on another object and allowed to add more fields and functions. How hard is it to write a query to grab this? You have to actually look at the tables to do this.

        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.

-- SQL syntax? its not that hard. Its easier than learning a new programming language and you guys do that all the time. The biggest difficult comes from developers who frequently switch databases. Since the syntax changes. I agree, that would be a real pain. Not sure how that is any different than switching from NoSQL to some other type of non-sql database though.

What a confused article (1)

jbolden (176878) | more than 2 years ago | (#40664237)

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 being to drive up the performance of the developers by embedding the intermediate layers directly in the database. This loses both flexibility and often performance in exchange for moderate reductions of development cost and development complexity.

Relational is a compromise between a bunch of conflicting goals. If you can't afford to compromise you can't use relational. But this article which takes all the advantages of a variety of NoSQL approaches and intermixes them as if you can get them all together rather than they are pulling in opposite directions.

Programmers should not be allowed to write SQL. (1)

pigiron (104729) | more than 2 years ago | (#40664247)

All database access should be done through stored procedures written by people competent in the relational model.

Programmers should be allowed to write SQL. (1)

DragonWriter (970822) | more than 2 years ago | (#40664501)

All database access should be done through stored procedures written by people competent in the relational model.

Well, no. All non-administrative access to a database should be through views configured by someone competent in the relational model, but those views should be accessed through SQL also written by people competent in the relational model. Competence with the relational model is a fundamental skill that all professional programmers should have.

ignoring history, are we? (5, Informative)

sribe (304414) | more than 2 years ago | (#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 (2)

ianare (1132971) | more than 2 years ago | (#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.

There really is no contest... (1)

smcdow (114828) | more than 2 years ago | (#40664275)

emacs

fork vs spoon: Which Is Better? (0)

Anonymous Coward | more than 2 years ago | (#40664329)

They are complimentary.

IMO, the issue isn't SQL vs NoSQL (1)

C_Kode (102755) | more than 2 years ago | (#40664405)

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

SQL has strengths that make it hard to move away from. If you are going to move away from SQL, then you probably already know NoSQL's pluses, but do you know NoSQL's limitations? Not only that, but do you know where your project will end up? If not, you better think long and hard about moving to NoSQL because down the road, that feature or functionality you need may be damn hard to implement using NoSQL.

There are been a lot of projects that started with NoSQL and are now SQL based.

no need to even disagree (1)

Biggseye (1520195) | more than 2 years ago | (#40664417)

Having been in information systems for 35 years, I feel that whole argument is salacious. Having user many different databases, many different languages, I have found that in the end, it is best to use that database/language that fits the application best. Of course you have to take in the skill set of the available resources. But the ultimate goal is to produce a product that is usable and fills a need. You can argue forever what is the best to use, and get nothing done. Been there, done that, have the scars to prove it.

In this SQL happy industry... (0)

0p7imu5_P2im3 (973979) | more than 2 years ago | (#40664473)

I see no benefit to SQLs as they are typically just regurgitation and rehash of the previous platform. Yes, there is some minor benefit to being able to forgo character exposition, but often they are simple cookie cutter copies of other SQLs... Wait... we're not talking about movies, are we?

DBA Threat (1)

codepunk (167897) | more than 2 years ago | (#40664521)

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.

Bogus false conflict (1)

mlwmohawk (801821) | more than 2 years ago | (#40664543)

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" data is an access strategy, not a requirement.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>