Slashdot Mirror
SQL Vs. NoSQL: Which Is Better?
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."
SQL and NoSQL are different, with different use cases.
Well, at least not better overall. Each solution may be more suited to solving a particular problem. You can also use both, or neither!
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
"No".
No points for guessing the author's answer to the question posed by the title.
I use whatever RMS uses, so yeah.
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).
Which one is web scale?
Well, the bicycles uses no Gas, but the Bus can carry 50+ people in a single trip. So which is better?
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
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.
SJW n. One who posts facts.
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.
SQL is waaaaay too structured!
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.
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."
My sci-fi novel, Ghost Thief, is now available from Amazon.com.
nt
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...
We don't need yet another new programming language. Let's just pick an existing language and fix its flaws.
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.
Shampoo is better! I go on first and clean the hair!
that slashdot editors still cannot figure out how to select link text that actually corresponds to what is being linked to?
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*
My work here is dung.
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.
> 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
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.
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.
Maybe Slashdot should stop posting shit with ridiculously transparently flamebaity headlines just to generate hits...
Cats vs dogs. Etc.
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
http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale
:-)
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>
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.
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.
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!
We'll make great pets
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.
"I don't know, therefore Aliens" Wafflebox1
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 ?
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
"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.
Jesus was a compassionate social conservative who called individuals to sin no more.
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.
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.
All database access should be done through stored procedures written by people competent in the relational model.
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 ;-)
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.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
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.
emacs
In the course of every project, it will become necessary to shoot the scientists and begin production.
They are complimentary.
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.
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.
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?
Resistance is futile. Your technological distinctiveness will be added to our own. You will become one with the morgue
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.
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.
Got Code?
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.
Can't but help but think of this whenever I read about this argument. http://www.youtube.com/watch?v=b2F-DItXtZs
Speaking as a professional SQL Developer with OVER TWENTY YEARS of experience, an RDBMS is not the answer to every problem. Sometimes NoSQL makes sense.
For example, if I'm dumping some random user data that will never be formatted/standardized/normalized—that can be different domains for every user—NoSQL might be the right choice.
Maybe I want to store a user's favorite object (puppy, car, toy, steak 'doneness') and I don't want to have a child-table-from-hell lookup table. NoSQL is a great option.
On the other hand, if I want to do some sort of row lookback, then it is far easier in a relational DB. For example, if I want to find the salary average and of all of people in the same department as the most recent new hire or the average working 'lifespan' (how long before the person quits, gets fired or dies) of every department vs. their salary range*, then it is pretty easy.
Now get off my lawn.
* Yes, real-world examples.
Yeah, right.
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 ...
THE HONOUR OF THE KNIGHTS - CC Licensed Sci-Fi Novel
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.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
Did you forget to link to the link?
Yeah, right.
I hope this doesn't come off the wrong way, but where's the god-damned link?
I'm tagging this as missinglink.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
You should be asking:
SQL Vs. NoSQL: Which Is Better For What?
Coder's Stone: The programming language quick ref for iPad
just let those nosql folks reinvent xml and let them be.
Dolphins or bathos?
Brilliant troll. Mad props to you, sir.
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.
People aren't so much on the fence about that one though.
I learned SQL ages ago, and never used it very much. After a year or two of complete non-usage, I had to do something with it again, and realized I can still write perfect SQL.
Not many human-computer-interfaces are great like that. After all, I'm the weakest link in the computation now (and the scarcest resource as well), so I love the kind of thing SQL is.
Wake me up when its real news...
The conclusion "It just depends" is true, but not very useful. There is some initial confusion here where we act like Google does "data processing". Google does "information processing". Would you want your bank to use the Google style of information retrieval to calculate your checking account?
Plus, we need a bit of strategic thinking here. All large corporations should have and use a Data Architecture which includes two major components - Add, Change, Delete data stores and Reporting/Querying data stores (from which Information is garnered). There is a fundamental rule - There can be no end-user querying against the Add, Change, Delete data stores. Twenty five years ago, Bill Inmon observed that with this architecture you have "underhead". But in addition to the simplicity inherent in this fundamental data architecture we should take into consideration that we can make as many copies of the Reporting/Querying data stores as we want. This all by itself handles the issue of many many users of a single data store. But in addition to mearly copying the Reporting/Querying data stores we reduce the size of each segment by some tactical criterion - geography, customer type, goods purchased, etc. Proper data architecture solves the problem being addressed by NoSQL in typical corporations - Amazon, Bank of Americal, Smith Barney, State Farm, etc. NoSQL is a better tool for information corportions like Google.
I beg your pardon, but that's bs by someone who wasn't there.
There was *zero* discussion of SQL in the late seventies into the mid-eighties, when I was studying. Everyone used heirarchcial databases. Not a college, not a nation board, not a Fortune 500 company, used SQL. The first time I ever *heard* or worked with SQL was '91.
But then, there are such fads in comp sci, and the latestgreatestnewestcoolest tool is the Answer To Life, the Universe, etc. Why, I remember the Jan '94 IEEE Spectrum, that *literally* presented OO as The Silver Bullet to the software backlog....
mark "has hammer, and screwdrivers with flat, Phillips, torx, etc heads...."
What are the characteristics of problems that make one better than the other? I see many posts arguing that it all depends on the problem (which almost anyone with a modicum of knowledge and an open mind can conclude), but very few indicating how the characteristics of the problem affect the outcome.
For that matter, what *is* a noSQL data base. Clearly, from the debate here, it's not a relational data base. But this doesn't tell me what it *is*, what facilities it *does* provide.
Please, please enlighten us on these matters, rather than just spewing parametric (but, I admit, amusing) boilerplate.
(I was about to ask, "Can anyone please ...", for which the answer would trivially and uninformatively be "yes".)
I was tweaking the AC's reliance on Argumentum ad Verecundiam, which is (often) a fallacy.
I looked up alternatives to Alzheimer's, and Pick's Disease looks like an introvert-troll/basement-dweller's dream. Check out the list of behavioural and emotional changes.
Yeah, right.
As a retired software developer I am sadened by the demise of the
emacs/vi ah err fights. They supplied humour for many years. I still
have trouble with emacs modes in things like Netbeans because my
finger tips still remember all of those sexy little short cuts I used every day.
sigh!
If I had to choose between SQL, NoSQL or not having that choice and instead selecting a schema design that did not suck guess which option I would pick every time?
You can always tell the clueless "data experts" they are constantly neaping about database size, queries per second, join performance...etc.
While the less clueless in realitive terms only care about minimizing contention.
I say this entire thing comes down the preference of the developer. You can compare benchmarks and compare syntax and ease of use and go on and on and on but in the end all that really matters is how the developer feels. Personally I don't care, you can sit me down at any database and I'll learn it.
The conclusion "It just depends" is true, but not very useful. There is some initial confusion here where we act like Google does "data processing". Google does "information processing". Would you want your bank to use the Google style of information retrieval to calculate your checking account? Plus, we need a bit of strategic thinking here. All large corporations should have and use a Data Architecture which includes two major components - Add, Change, Delete data stores and Reporting/Querying data stores (from which Information is garnered). There is a fundamental rule - There can be no end-user querying against the Add, Change, Delete data stores. Twenty five years ago, Bill Inmon observed that with this architecture you have "underhead". But in addition to the simplicity inherent in this fundamental data architecture we should take into consideration that we can make as many copies of the Reporting/Querying data stores as we want. This all by itself handles the issue of many many users of a single data store. But in addition to mearly copying the Reporting/Querying data stores we reduce the size of each segment by some tactical criterion - geography, customer type, goods purchased, etc. Proper data architecture solves the problem being addressed by NoSQL in typical corporations - Amazon, Bank of Americal, Smith Barney, State Farm, etc. NoSQL is a better tool for information corportions like Google.
Dick
Exactly. The best response to "which is better?" is always "at what?". You cannot answer the first question without answering the second.
My customers ask this question all of the time -- who's better? The answer isn't which is better, but which CAP properties do you want. You want consistency -- go with SQL and get the data model right to optimize performance. You have situations where availability and partitionability are important -- let's develop a matrix of noSQL solutions based on what data you're going to ingest. XML, you say? mongodb is probably the best fit? Trawling over metadata? Key-value stores are better. Etc. Etc.
The one place where there is a substantial difference is geospatial indexing -- noSQL databases appear to do this a lot better than the SQL databases. YMMV, though.
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.
Yeah, it even has stored procedures (they are called executables). And you can write those in any programming language you like!
The Tao of math: The numbers you can count are not the real numbers.
As any TRUE old timer will tell you, SQL makes things slow and complicated and NoSQL sounds like the name of a boy band. Ditch them both and go back to tab delimited text files! Nothing beats a flat file!
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.
Ya, the Vi vs. Emacs wars are still going on in some places. When will those geeks ever learn?
SQL is used for relational databases.
NoSQL is used for DSS views of data, for which an RDBMS may not be the best choice.
If the world you look at is flat, or you look at it in layers (eg a GIS) than a different tool might be a wiser choice.
Life is not a binary Either Or choice. It is a multiple choice statement and you can check zero, one, or many boxes.
-- Tigger warning: This post may contain tiggers! --
subject says it all ;-)
Mostly. Yeah, there's lots of data that's not in any real form of database.
If only we had a way to work with the relational model without using the horrible data access sublanguage called SQL...
SQL does NOT scale for many kinds of problems. To take an extreme example, let's say you had a network design for the United States telephone system, with all its connections and hubs and exchanges etc and how they all connect together. Then you want to store it all in a database. These kinds of problems will crush an SQL database. Sure, a really good SQL database can handle remarkable numbers of transactions per second, where those transactions are relatively simple: some manageable number of records involved per transaction. But the more complex the problems become, the more the theory bogs down. With more and more complex web sites and problems being modelled, the less and less can SQL databases cope.
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.
Both are way too overpriced and impractical for my modest needs. So by way of analogy, you're implying that there's a better light-weight alternative to both!
There's only one way to find out.
FIGHT!
If you don't have an opinion, start with an SQL database. If you've got what you think is a specific use case, you've done your research, and have prototyped up a demo, then consider a NoSQL solution.
Right now, NoSQL isn't safe enough for noobs to use, but a run-of-the-mill MySQL or whatever is easy to get to "good enough". Until you run out of puff from that, keep out of NoSQL.
IF you really truly need a DB, then SQL is usually a better choice for no other reason than there are several vendors offering several levels of capability all more or less compatible with the SQL language. Obviously there are times when your domain requires NoSQL, so know your domain and choose the right tool. But if you don't know yet, it's probably wiser to start with SQL.
Of course, as others have pointed out, often when people think they need a DB, what they really need is a hash table and maybe a text file.
You are conflating the physical storage mechanism with the query language. Ideally one could use the same query language (such as SQL) regardless of whether the data was in an RDBMS, XML, or CSV "flat" file(s).
I'm all for exploring different query languages, and have even drafted up one of my own ("Smeql"), but the end-goal should be separating query language choices and physical storage layout choices.
Then we could debate query languages separately from storage techniques and perhaps even mix and match.
But in reality, our current choices are indeed limited. Google doesn't seem to be on the right track to give us flexible choices.
Table-ized A.I.
The earlier relational languages were more math-like than SQL, and thus more flexible. For example, you could have a named-reference to a repeating structure rather than have to actually repeat that structure, and the optimizing engine would (potentially) know how to factor the actual under-the-hood query to avoid multiple trips to disk.
Thus, multiple syntactic references didn't necessarily have to be multiple disk references. (It's somewhat similar to "views", but easier to use in a given expression and better used by the optimizer.)
SQL was created sort of in the COBOL vain where the code was semi-readable to managers. It was easier to sell to PHB's that way. Lost was the elegance of the math-like approach.
They tried to please the suits, not the geeks. Part of the claimed appeal of the COBOL-like syntax was that non-programmers could write queries because "it's English-like". While true, it did limit the expressiveness for advanced query writing, and thus SQL can become long, run-on sentences, and repetitious for the more complex queries.
Table-ized A.I.
because that will maximally dissuade management from launching all their brilliant projects, and experience tells us that the net result of the majority of such projects is to make things worse.
The reason PostgreSQL scales is that Slashdot posters seem to like it. I've never seen science on this level done live before my eyes before!
Use tables that only have a ++id, and a blob.