×

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!

Why Some Devs Can't Wait For NoSQL To Die

Soulskill posted about 4 years ago | from the must-be-the-insurance-policy dept.

Databases 444

theodp writes "Ted Dziuba can't wait for NoSQL to die. Developing your app for Google-sized scale, says Dziuba, is a waste of your time. Not to mention there is no way you will get it right. The sooner your company admits this, the sooner you can get down to some real work. If real businesses like Walmart can track all of their data in SQL databases that scale just fine, Dziuba argues, surely your company can, too."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

444 comments

Article summary (5, Funny)

BadAnalogyGuy (945258) | about 4 years ago | (#31647550)

People who don't like SQL should get their heads out of their asses and use MySQL, a robust and enterprise-ready database.

Interesting thesis...

Re:Article summary (5, Insightful)

digitalunity (19107) | about 4 years ago | (#31647606)

My experience has made me believe PostgreSQL is better in every respect. It's more stable, has more features and is easier to use. The article wasn't specifically pro-MySQL.

The article is largely correct. The movement to ditch SQL databases is really naive. SQL scales just fine, if you know how to use it right. Look at Oracle solutions. All their fancy eBusiness software is still Oracle SQL DB backed and some of the biggest companies in the world are using it.

SQL isn't the problem, it's a tool. Bad programmers are the problem.

Re:Article summary (4, Interesting)

RedMage (136286) | about 4 years ago | (#31647704)

We're using both - about five days from our "go-live", and things look good. We just use what makes sense for each part of our application.
For us, this means PostreSQL for the parts that must be transactional ACID, and Amazon's S3 and SimpleDB for parts that don't. In practice, for the 1.0 release, this means things like notes, user accounting, and documents are in S3 and SDB. The rest is plain ole SQL.

Not that there wasn't a learning curve with our developers - we're a bunch of old-time enterprise type developers, so "letting go" and moving out of the traditional SQL world took a little thought and proving time. We'll use the first few months to learn more about doing architecture this way.

We've had the language wars - lets avoid the SQL/NOSQL wars please. I'm tired.

Re:Article summary (1)

MooUK (905450) | about 4 years ago | (#31648116)

Would it not have been less complex to use PosgreSQL for everything, or was there enough difference to be worth the complexity?

Re:Article summary (1)

amorsen (7485) | about 4 years ago | (#31647710)

SQL isn't the problem, it's a tool. Bad programmers are the problem.

Relational databases are quite useful. It's too bad they're hampered by such a lousy syntax though. It's like if we all decided to stick with COBOL but added closures and templates and whatnot...

Re:Article summary (4, Insightful)

deniable (76198) | about 4 years ago | (#31647804)

Some of us are simply looking to not use the relational model for *every* bit of data in the system. Application global, put it in a table. Uploaded files, put them in a table. User data, get it from LDAP, nah, create our own table and get somebody to feed it manually. Given the number of apps I've seen that use SQL as a simple key/value store, it's no wonder that there are techniques to avoid the overhead completely.

Re:Article summary (3, Insightful)

dimeglio (456244) | about 4 years ago | (#31648288)

I suppose it's the same argument when having to choose a development language. You got to pick 4GL languages, VB, Pascal, c++/Java/c#, assembly, and machine languages. The art of a great analyst is to know which to pick and when.

Re:Article summary (1)

timeOday (582209) | about 4 years ago | (#31648012)

I agree, the syntax of PROLOG, for example, seems much simpler, more powerful, and makes more sense to me. There have been many attempts to fuse it with SQL, but nothing past the scale of a few researchers from different universities working together.

But when all is said and done, you can get familiar with most of SQL in a couple weeks. No doubt mastering all the intricacies of Oracle takes years, but not, I think, due to the SQL syntax.

Re:Article summary (4, Insightful)

slim (1652) | about 4 years ago | (#31647754)

Look at Oracle solutions. All their fancy eBusiness software is still Oracle SQL DB backed and some of the biggest companies in the world are using it.

Yep, "nobody ever got fired for choosing Oracle".

But to get performance and fault tolerance for Oracle, you need to throw a lot of money at it -- high end hardware, RAC licenses etc. Whereas some of the NoSQL DBs promise lots of scalability on clusters of cheap hardware -- situations where failing hardware is the norm.

If your application suits it (i.e. your data fits the name/value system, and eventual consistency is adequate) why not use something fast and cheap?

Re:Article summary (0, Flamebait)

Anne Thwacks (531696) | about 4 years ago | (#31647904)

nobody ever got fired for choosing Oracle

I would definitely fire anyone who specifies Oracle in my organisation. Oracle have shafted me twice by dropping support for a product with inadequate notice. Its either Postgresql or DB2 for me, unless MySQL is the best choice.

I would also fire anyone who specifies MSSQL - with immediate effect, and no severance pay: On grounds of insubordination, incompetence and reckless endangerment. As for people who think SQL means MSSQL - they are either too ignorant or stupid to be employable.

Re:Article summary (2, Interesting)

nacturation (646836) | about 4 years ago | (#31648006)

I would also fire anyone who specifies MSSQL - with immediate effect, and no severance pay: On grounds of insubordination, incompetence and reckless endangerment.

So it's a no-go on MSSQL for that Microsoft contract your company just got? Of course, you didn't specify the type of work your company does so this attitude comes across as being rather narrow-minded. And good luck on that no severance pay thing. "I'd fire anyone in my organization who suggested we callously disregard labor laws like that." :)

Re:Article summary (-1, Flamebait)

BlortHorc (305555) | about 4 years ago | (#31648280)

Dude, ignorant much?

SQL Server is a piece of crap, the only reason I have ever seen people use it because they are MSCE fanboys, you want a real enterprise DB, SQL server ain't it. You want a cheap but reliable DB, it is still not it. SQL Server only exists because there are a sufficient number of dumb fucks who think they won't be fired for buying MS.

Re:Article summary (0, Insightful)

Anonymous Coward | about 4 years ago | (#31648102)

No one wants to work for you or from your mother's basement anyhow. Perhaps if you weren't such a rude, close minded fool you'd do better.

Re:Article summary (4, Insightful)

Vancorps (746090) | about 4 years ago | (#31648148)

What product has Oracle ever dropped support for? What is your objection to MSSQL? SQL 2005/2008 are damn fine products which perform extremely well. Sounds to me like you're the one that is ignorant with blanket policies against industry standard tools.

Of course I run Oracle, MySQL, and MS SQL in my datacenter all without problems and some under nice and heavy loads. About the only sensible stance you have is with Postgresql which is far and away better than MySQL which in my opinion sucks pretty bad.

Re:Article summary (0)

Anonymous Coward | about 4 years ago | (#31647758)

Wrong. The reason people are against SQL is because they're using generic cheap intel machines, and not designing systems that are scaling across hundred or thousands of servers. Most people complaining are not financial or transaction based systems, they're shitty websites with a large number of active users. E.g. FB and digg. Once SSDs come in large storage solutions, people will be complaining about SQL a lot less. If you think oracle is fast, you've never used it.

Re:Article summary (1)

Nerdfest (867930) | about 4 years ago | (#31647768)

Sure you can scale SQL databases. The real point is that it takes a lot more work to do it than with a NoSQL database, and in some cases the advantages of SQL aren't worth the hassle. It depends on what problem you're trying to solve and what your other constraints are.

Re:Article summary (5, Interesting)

squiggleslash (241428) | about 4 years ago | (#31647932)

There's a fairly obvious reason for NoSQL vs Pro-SQL, and it's this: SQL is absolutely the worst database query language ever invented... apart from all the others.

Virtually no-one who's spent any time analyzing and working with large amounts of data has a good word to say about SQL. It was designed from the start as a language that would be integrated into others, and yet simple real world realities make that impossible, with 99% of implementations being of the "Build a large string, and pass that string to "the SQL connector" to be parsed and interpreted" form. Its handling of null and the empty string is incomprehensible and useless, in part because nobody involved ever had the cajones to do what needed to be done with both. There is no standardized set of data types in the real world. Simple issues with unstandardized case dependencies can make an application that works with Oracle and only uses standard "select" statements not work under, say, PostgreSQL. And these are the surface level technical issues: talk to any relational database guru and they'll come up with numerous philosophical issues too.

To this you add another component that's always an issue: the entirely haphazard way in which relational databases are implemented on most operating systems, whereby the DBMS is another application, that manages its own files, and needs to be coached with kind words and a happy smile in order to get anything done. Does your app use a database for something back-endy, like, for example, MythTV does for its settings and lists of channels and TV programs? Well, either forget it, or be prepared to put your users through hell as they have to ensure that the entirely separate DBMS is installed and that usernames and passwords are set up for your application's use.

And so, naturally, people hate them. With a passion. To the point that anyone sane is going to put it low on the list for any application, even when it's entirely appropriate. Of course your multiuser databases in your enterprise environment should be stored using an enterprise grade RDBMS, and as nobody's come up with anything better, you should be talking to it using SQL.

...and you should be talking to it carefully. Ideally, those writing the application core should be handing over the database access to someone who can abstract each query properly. Because SQL sucks. It just sucks less than anything else designed to do the same thing.

Re:Article summary (5, Insightful)

seanadams.com (463190) | about 4 years ago | (#31648076)

Does your app use a database for something back-endy, like, for example, MythTV does for its settings and lists of channels and TV programs? Well, either forget it, or be prepared to put your users through hell as they have to ensure that the entirely separate DBMS is installed and that usernames and passwords are set up for your application's use.

sqlite is underrated and would be ideal for many such applications.

Re:Article summary (2, Interesting)

Anonymous Coward | about 4 years ago | (#31648270)

... were it not for the fact that SQLite is at least two orders of magnitude slower than any other database, including ones written by first year comp sci students.

Re:Article summary (4, Interesting)

ducomputergeek (595742) | about 4 years ago | (#31648112)

I don't have mod points, but I've found the same thing. It's the perfect development database if you think that your program is ever going to need to support Enterprise class stuff. On the small scale, I've found that it's fast enough. Is MySQL faster? Yes, but where I've tested it's not been enough to really matter compared to the other advantages of PostgreSQL. Primarily that it's ACID compliant. What we've found is that it works well until you start getting into databases that are GB in size. But then you can easily port the datatables to DB2 or Oracle and go. Especially if you designed the rest of the software to do this from the get go.

In production, we moved all but one of our databases from MySQL to PostgreSQL. We were having problems with Innodb corrupted once every couple months. When it was announced that Oracle was bidding on Sun, we ported over to PostgreSQL, spent a couple weeks rewriting code, and we've not touched the Postgres database since. It's not corrupted and not even hiccuped once since we deployed. We run regular vacuuming and maintenance and that's it. It's been humming for well over a year and now is getting 400x's the use than we ever had with MySQL.

The only thing that PostgreSQL was lacking has been HA support. There are number of 3rd party tools that run well, PGCluster, Slony, GridSQL, but this looks like PostgreSQL is going to support native replication, clustering, and HA with hot-standby...

Re:Article summary (2, Interesting)

JamesP (688957) | about 4 years ago | (#31648208)

SQL isn't the problem

Yes, it is

Overhead caused by structuring your data the way relational dbs needs.
Lack of flexibility
Scalability capabilities (horizontal scaling is easier)
Speed (see overhead)

Re:Article summary (2, Interesting)

SanityInAnarchy (655584) | about 4 years ago | (#31648212)

SQL isn't the problem, it's a tool. Bad programmers are the problem.

You could say the same about assembly language. You could also say the same about threads, and dismiss things like functional programming and the actor model as fads.

I'll give you a simple example: Given a big transactional SQL database, if you want it to scale to more than a few machines, you're going to want to shard it. That's going to be a ton of manual work, figuring out what you can shard, what keys to shard it on, adjusting it later on the fly to ensure that each DB server has exactly what it can handle in terms of data and load, and so on. You might be able to write software to do this for you, but that software is going to be fairly tightly coupled to your data model and your app.

It's possible I'm missing something there, and it's possible there's an easier way to do it, but it seems like every way to scale SQL has similar tradeoffs. Put a proxy in front of your DB cluster, giving the impression of a single database out of those shards? Your app is now not talking directly to the database, and certain queries won't be supported, and certain other queries will be slow or unreliable.

The database I'm working with now is Google AppEngine. It's pretty much natively sharded, and the tradeoffs are understood up front -- you can only transact over entities in the same group, but if your app is built up front to define entity groups appropriately, Google can physically shard them for you. It's a similar advantage to using Erlang for concurrency -- you probably won't be running your Erlang app on a machine with several thousand cores, but if you've got several thousand concurrent actors, it will trivially scale to anything in between.

Like Erlang, it's also not a magic bullet. I still use SQL in things like SQLite, because it's the best tool for the job.

The Actual Quote is (5, Insightful)

Daengbo (523424) | about 4 years ago | (#31647630)

"MySQL or PostgreSQL," for what it's worth. PostgreSQL is a pretty powerful database, and you should have to make a pretty good argument why leaving a well understood technology that powers a lot (an some of the largest parts) of the WWWeb needs to be trashed for something newer and less tested.

There are times... (2, Interesting)

lenski (96498) | about 4 years ago | (#31648328)

Our development organization is heavily invested in PostgreSQL, finding it to be perfectly matched to almost all of our needs. It is exceptionally reliable, and is very (but not perfectly) manageable. (We've had issues in the past with mis-timed auto-VACUUM for instance which are now resolved.) We even found a small but significant corner-case bug which upon being reported, received immediate attention from the developers, resulting in a resolution in under 72 hours. I believe our use of this particular tool has saved us significant resources (dollars, developer time) that has allowed the development organization to direct our time and money to our own application development.

But we're finding that even PostgreSQL has limits, mostly with respect to the large and growing datasets our application uses for large scale real time control. We could transition to a really expensive SQL solution, but we are at least considering the choices that may be a better fit for these particular subsystems than PostgreSQL or any other SQL solution. Just a few weeks ago, we started seeing a good comment in teh interWebs... "NoSQL" should mean "not only SQL".

Not a rejection of a powerful toolkit that holds a central role in our organization, but rather a recognition that we would be remiss in our responsibilities if we didn't pay attention to the choices that could simplify our lives as developers.

Can't wait it to die? (2, Insightful)

sopssa (1498795) | about 4 years ago | (#31647552)

This is like saying "I can't wait for memcached to die" just because your site doesn't need it. Fact is, some do. It's your own fault if you choose to apply unnecessary techniques.

Don't change to newer fancy techniques if you don't understand what they are for and why would you need them.

Re:Can't wait it to die? (2, Insightful)

David Gerard (12369) | about 4 years ago | (#31647588)

memcached is most useful when the underlying app is hideously inefficient, e.g. it's pretty much essential to a MediaWiki installation that gets any appreciable number of users.

Re:Can't wait it to die? (1)

outZider (165286) | about 4 years ago | (#31647680)

Well, no, not entirely. Not many sites out there run purely from memcached. Memcached is a component of a larger architecture. The fact remains that technologies like NoSQL are usually used/desired by people who have no understanding of system architecture, design an inefficient application, and then blame the database software for their poor decisions.

Re:Can't wait it to die? (3, Interesting)

Anonymous Coward | about 4 years ago | (#31647752)

Facebook.com, the highest-traffic site on the Internet, serves more than 95% of its data out of memcached. Twitter, Wikipedia, etc are major users too. And of course, Google serves its web index out of memory.

Re:Can't wait it to die? (0)

Anonymous Coward | about 4 years ago | (#31648114)

Facebook and even tweeter are slow!

Right! (1)

For a Free Internet (1594621) | about 4 years ago | (#31647556)

NoSQL is a product of the braindead and buzzword-infested effluents of the American "education" system, where nobody understands math or logic.

Re:Right! (2, Insightful)

WrongSizeGlass (838941) | about 4 years ago | (#31647832)

Everyone's needs are different, and there are going to be different solutions for those needs. If NoSQL isn't for you then just don't use it (don't spend any time learning it, try it out, running a site with it, etc, etc). I don't have a need for it yet, but we do all sorts of sites and programming so who knows if it will be the right solution for one of our future projects? I won't unless I learn about it, test it and get my hands dirty with it.

And as far as it being 'a product of the braindead and buzzword-infested effluents of the American "education" system, where nobody understands math or logic', I don't care if it came from the bottom of a well in the middle of a jungle where they are masters of logic and math, if it could possibly meet my client's needs then I'm going to give it the time and attention it takes to make the decision for myself.

Neither are going away so just shut the fuck up (1, Insightful)

Anonymous Coward | about 4 years ago | (#31647568)

Hierarchical DBMS have been around longer than SQL-style RDBMS for a long time. OODBMS have existed for a long time as well. Many of these "NoSQL" DBs don't provide the same restrictions or assurances that an RDBMs provides but they often have other features.

BDB isn't going away and neither is SQL. Get over it.

Dear fellow AC; (0)

Anonymous Coward | about 4 years ago | (#31647874)

I'm a blogger that doesn't really have anything worthwhile to blog about so I make up bullshit things to post on my blog. Now, if you consider the millions and millions of blogs out there, it's impossible to get noticed if you have a thought provoking, insightful, honest opinion. Therefore, I have chosen to write "Trollish" and "Flamebait" "articles". So far, as you can see, it has worked quite well.

Granted, I offer nothing to knowledge and ongoing debates and conversations, but I have this fantasy that I can make money from my blog and leave my boring and monotonous IT job.

Your truly;

Some dipshit blogger.

Adding more garbage to the stinking pile of the internet.

I can't wait for databases to die (5, Funny)

Anonymous Coward | about 4 years ago | (#31647634)

XML text files all the way! /duck

Re:I can't wait for databases to die (-1, Redundant)

yeshuawatso (1774190) | about 4 years ago | (#31647766)

right, bacause programming with XML is so much easier and efficient. Don't take my sarcism the wrong way; XML has its advantages (human readable, cross compatible) but it is by far the worst way to go for time critical, multiple transaction programs.

Why? (2, Insightful)

ThoughtMonster (1602047) | about 4 years ago | (#31647648)

Why should anything "die"? People choose solutions based on their individual merits. If something doesn't work, exchange it for something that does. I'm sure certain people find NoSQL-type databases perfect for their needs.

In short, people should just shut up about other people's choices and get on with their own.

Re:Why? (1)

lukas84 (912874) | about 4 years ago | (#31647802)

People choose solutions based on their individual merits.

No, just no.

Re:Why? (2, Insightful)

Jeff DeMaagd (2015) | about 4 years ago | (#31647910)

No, just no.

That's about as information-free as one can get. I'd ask why, but then, I don't understand why I would have to, just saying "no" is void of context and explanation.

Re:Why? (0)

Anonymous Coward | about 4 years ago | (#31648276)

Because this whole NoSQL hype is bullshit. Like with every other hype people hardly know what they are talking about.

Like people see that Cassandra is a member of the NoSQL group. Cassandra has very good scalability. So they conclude that NoSQL scales better than RDBMS. Bullshit. Cassandra scales better because of eventual consistency. This has nothing to do with NoSQL. Not all NoSQL members have eventual consistency. In fact very few have that. And there isn't a reason why a RDBMS couldn't make the same trade of weaker consistency for better performance.

NoSQL is such a large group that every claim I heard until know is absolutly worthless. The only thing the members of the group really have in common is that their main interface isn't SQL.

Someone please explain to me how the properties of Cassandra could possibly be projected on any other NoSQL database. What does Cassandra have in common with db4o? This NoSQL hype has to stop. Instead talk about how great each of its members are in their own problem domain.

There's a place for SQL, but there are some... (2, Informative)

BLToday (1777712) | about 4 years ago | (#31647678)

There's a place for SQL, but there are some cases where BigTable-like (ie. HyperTable) works better. Our company manages data using SQL, but when we present data to the users it's through a HyperTable implementation. SQL is easier to data management but HyperTable uses our server resources better.

Hardware is cheap. Developers aren't. (5, Interesting)

Anonymous Coward | about 4 years ago | (#31647684)

It's really that simple. A standard dual socket server with the latest CPU's from Intel or AMD can handle hundreds of requests per second; if one isn't enough, just add more hardware, one month of salary can buy you another node, a year can buy you a whole cluster of rackable systems or a chassis full of blades. If it takes a few months extra for a team to solve the problem the NoSQL way, that's a few months of extra salary costs and missed sales.

Slashdot runs on SQL. I run a site of 1M pages daily (1/3-slashdot according to Alexa) with just a single system with 2x Xeon E5420, Django/PostgreSQL at 10% load. Unless you attract enough attention to require scaling past 10M pages a day, you're wasting your time reinventing the wheel with NoSQL, just stick with a standard ORM, launch your site and start convincing customers and generate sales. You can survive a slashdotting just fine without spending so much time on those exotic tools.

Re:Hardware is cheap. Developers aren't. (-1)

Anonymous Coward | about 4 years ago | (#31647816)

1M pages makes no sense, unless it is put into context. If you look at google search engine, it has just 2 pages, one home page and one search results page. Do you believe it will run on Pentium 4, then?

So could you elaborate on your website. 1M Static or Dynamically generated pages? and do you use the database at all, and if so, do you search and match huge tables in your queries? Or do you ofload your Database activity to another server, and have a relatively good bandwidth between your servers to handle the data?

Re:Hardware is cheap. Developers aren't. (4, Informative)

pavera (320634) | about 4 years ago | (#31647872)

Pretty sure he meant 1M page views/day as he compares it to slashdot using alexa data.... Is reading comprehension really that hard? Context clues are your friend.

I run a site using django/postgres, we do about 100k page views/day on a 512Mb 10GB Virtual machine. Its not doing anything crazy like google, but yeah, we aren't close to needing more power yet. When we do, first thing we'll do is bump up RAM for increased cache space...

Re:Hardware is cheap. Developers aren't. (1, Informative)

Anonymous Coward | about 4 years ago | (#31648182)

Pure dynamic. It's a datamining / analysis site, so every user is viewing their own set of data, slicing and zooming randomly. Caching is completely useless for 99.9% of the pages, but we do store some heavy "SELECT COUNT(*) ... GROUP BY ..." queries in memcached. We chose PSQL because it can handle the complex multiple table joins with many indexes required - just that one thing would mean endless pain in a non relational datastore.

If you still have any doubt, just write your code the easy way and grab Apache JMeter [apache.org] to benchmark your site on localhost. You'll be surprised how well even the dev server works, on an average page with ~10 queries, it takes only 50-100ms to serve a page. At 10/sec/core, extrapolated to 24 hours means almost a million pages/core. You can just take this and run it on a 8-12 cores node and survive any traffic surge imaginable, without cache. Add cacheing and I really can't see how a blog/news site/forum/CMS can ever require NoSQL to run, except when you reach "Facebook" popularity.

PS.: We aim for these numbers for a non cacheable page: 1s = slow but manageable. 0.2s = good. 0.1s or less = perfect.

ORLY? (1, Funny)

Anonymous Coward | about 4 years ago | (#31648044)

You can survive a slashdotting just fine without spending so much time on those exotic tools.

Care to provide a link to your site so we can test this?

Re:Hardware is cheap. Developers aren't. (3, Insightful)

Vellmont (569020) | about 4 years ago | (#31648156)


It's really that simple. A standard dual socket server with the latest CPU's from Intel or AMD can handle hundreds of requests per second;

Hundreds of requests for WHAT per second?

Your idea of "just throw hardware at the problem" isn't generalizable. Throw hardware at WHAT problem? For some problems, you're right. For others, you couldn't be more wrong. There's really no point in saying anything further.

Re:Hardware is cheap. Developers aren't. (4, Insightful)

Lazy Jones (8403) | about 4 years ago | (#31648170)

Unless you attract enough attention to require scaling past 10M pages a day, you're wasting your time reinventing the wheel with NoSQL, just stick with a standard ORM, launch your site and start convincing customers and generate sales.

Most of the buzz about these things comes from and is aimed at people who actually believe they'll build the next Facebook or Twitter. The fallacy is in their belief that it's the size/traffic of those sites that supposedly mandates NoSQL and not the simple data models. Some of the biggest, less spectacular projects out there run on PostgreSQL for example (Skype, Affilias = .info and .org).

Re:Hardware is cheap. Developers aren't. (1)

SanityInAnarchy (655584) | about 4 years ago | (#31648228)

I run a site of 1M pages daily (1/3-slashdot according to Alexa) with just a single system with 2x Xeon E5420, Django/PostgreSQL at 10% load.

Good for you -- that says nothing about how much you're actually doing for each page.

just stick with a standard ORM

As a rule, I do. I use DataMapper in Ruby. It's just that DataMapper has pluggable backends, some for SQL databases, some for more exotic things.

Re:Hardware is cheap. Developers aren't. (2, Insightful)

JamesP (688957) | about 4 years ago | (#31648268)

For the type of loads 'front-page' slashdot (and your site, most likely) gets, SQL fits fine. But even then, NoSQL may give you a run for the money.

Now think of the loads incurred in the comment tree of slashdot.

Also think how something like GMail or even Google Search would fit in an SQL scheme. It doesn't, not at least, with table juggling that would be very inefficient.

Some docs can't wait for Cardiac Clamps to die. (4, Informative)

Vellmont (569020) | about 4 years ago | (#31647692)

So you're in surgery for 3 hours doing a kidney transplant, having used your trusty medium vascular clamp that have served you for the past 20 years. You're finally done and the patient is in recovery, so you sit down to relax with the latest copy of JAMA. They've got a great article about the latest development of Cardiac clamps, and you think to yourself "Why not use a heart clamp for kidney transplants!" Brilliant. So you order up some new clamps from MedicalClamps.com, and use them on your next patient. The surgery goes fine, but 3 months later the patient is back in your office with a failed kidney. You open 'em up, and it's obvious the clamp exerted too much pressure on the artery, damaging it in the process. Stupid carciac clamps! You're not a heart surgeon!

Re:Some docs can't wait for Cardiac Clamps to die. (2, Informative)

WrongSizeGlass (838941) | about 4 years ago | (#31647918)

I think this would have been better if you'd used a car analogy ... maybe something with hose clamps?

Re:Some docs can't wait for Cardiac Clamps to die. (4, Funny)

gazbo (517111) | about 4 years ago | (#31648142)

You missed out the bit where the article about cardiac clamps talks about how much better they are than the old-fashioned medium vascular clamp. And how every subsequent edition of JAMA has several articles all trumpeting the glory of the cardiac clamps over the now-outdated vascular clamps (although all of these articles are written by first-year med students who have never actually performed an operation - but they did once have a nose-bleed and chose to use a cardiac clamp to stop it).

Analogies are FUN!

Just so you know (0)

Anonymous Coward | about 4 years ago | (#31647730)

Shut your whining.

You must pay attention to Ted Dziuba (0)

Anonymous Coward | about 4 years ago | (#31647756)

Say what you want about Ted but you must respect his technical opinions. After all, the man is well known for having a job at Google at some point.

Resources vs. Smarts (2, Insightful)

RedMage (136286) | about 4 years ago | (#31647798)

FTA:
"In the meantime, DBAs should not be worried, because any company that has the resources to hire a DBA is likely has decision makers who understand business reality."

Bad English aside, I just don't agree. Money != Reality. I have worked both sides of this coin - Startups with plenty of money but don't see the value in proper maintainance of the data store (one almost was put out of business by a disk failure), and very smart startups that are running lean but do understand the risks.

That said, on the deeper level, why does business reality == SQL? Sure I can scale Oracle to support massive DB's (and have), but I could probably get more value from using Amazon's SimpleDB for things that don't require massive scaling. Use the right tool for the job - Hammers are for nails, etc. Do the design work up front, decide how its gonna work, and the right tool should present itself.

Re:Resources vs. Smarts (1)

pavon (30274) | about 4 years ago | (#31648202)

Sure I can scale Oracle to support massive DB's (and have), but I could probably get more value from using Amazon's SimpleDB for things that don't require massive scaling. Use the right tool for the job ...

Isn't the entire point of these NoSQL databases that they offer better scalability at the cost of traditional ACID data guarantees? Why would you give up the flexibility and reliability of SQL if you didn't need massive scaling?

Walmart uses more than just SQL (0)

Anonymous Coward | about 4 years ago | (#31647810)

Strangely enough, Walmart does use more than just regular SQL to manage the data systems for all those items. OLAP systems provide much better
summarized system of data when SQL starts to bog down. I know this from doing tech support for them in the past.

No all databases are for business (1)

C3c6e6 (766943) | about 4 years ago | (#31647814)

I think the author of TFA is missing something: not all databases / datastores are developed for businesses to keep track of their inventories. These days, many scientific disciplines, such as bioinformatics, rely heavily on databases as well.

The latest experimental techniques produce so much data such that "old-fashioned" RDBMSs just don't cut it anymore. So, for certain application domains, NoSQL seems to be at the moment the way forward. I'm afraid the author can wish all the he wants but NoSQL is gonna be around for a while. Until something better comes up, that is.

Re:No all databases are for business (1)

jda104 (1652769) | about 4 years ago | (#31648238)

I think you're committing the same sin of which you're accusing the author, just on the opposite side of the pendulum.

Saying that all DRBMSs won't "cut it" for modern applications in any domain is pretty narrow-minded. It seems like a simple rule of thumb to me: put relational data in an RDBMS, put key-value data in a Key-Value DB...

As an aside, having worked on the Information Retrieval side of bioinformatics for the past few years, I've found that the complex side of bioinformatics is generally in the computation, not the retrieval. I've been well-suited by a single RDBMS server up to this point, though I have played around with MemCached for a couple of web apps.

Totally confusing... (1)

CoffeeDregs (539143) | about 4 years ago | (#31647820)

The article was stripped of all nuance and then injected with confusing bits. e.g.

>NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL

What? How was Rails marginalized by NoSQL?

Also, it's nice to see the whole BerkeleyDB-ish/key-value sector of the data storage world suddenly exploding with innovation. There's a lot of dogma on both sides of the NoSQL argument (and the name "NoSQL" doesn't help), but some of the many NoSQL tools look as though they'll be pretty useful. Cassandra and MongoDB especially. And big companies getting behind the growth of new tools is never a bad thing.

Dziuba is a troll. (0)

Anonymous Coward | about 4 years ago | (#31647846)

Look at his other blog posts and you'll realize he's just another all-knowing all-trolling developer. Screw him.

The Article Is Right... And Wrong (3, Insightful)

SQL Error (16383) | about 4 years ago | (#31647850)

Real business track their data with SQL databases, true. However, real businesses have small numbers of transactions relative to their value. If Walmart had the same revenue but the average sale was a tenth of a cent, their fancy SQL database would be smouldering rubble.

That's what Facebook and Twitter and other large social media sites are facing. Just try running Twitter's volume and Twitter's page hits and API hits off MySQL. It doesn't matter how many replicas you run, it's not going to work. Maybe you could run it on a cluster of IBM Z-series mainframes running DB2 - but where is the money going to come from?

Cassandra and HBase and the other distributed NoSQL database solve specific problems in specific ways. They won't work for Walmart, but they'll do the job just fine for Facebook and Twitter. If you have those specific scaling problems and can live with the restrictions (you lose ACID, indexes, and joins to varying degrees) then they'll work for you.

If all you know is that your site is running slow, then implementing NoSQL is unlikely to improve things.

Re:The Article Is Right... And Wrong (1)

ducomputergeek (595742) | about 4 years ago | (#31648160)

If you get to the size of Walmart doing anything, you have access to the capital to get a system from IBM or Oracle for OLTP and Teradata for data wearhousing.

Re:The Article Is Right... And Wrong (0)

Anonymous Coward | about 4 years ago | (#31648214)

Yep. I used to work at a place that did network analysis. There were huge volumes of data (think, something about almost every packet). We tried SQL based solutions. There was no way we could shoehorn it on the hardware. The solution was an in-house DB with only the thinnes veneer of SQL for the web front end. Almost certainly, the in-house DB wasn't proper SQL, but because it was custom, the non-SQL aspects were known. It fixed the problem.

Re:The Article Is Right... And Wrong (1, Interesting)

Anonymous Coward | about 4 years ago | (#31648326)

I've got news for you ... all the major stock exchanges, banks, and telecoms in the world use SQL RDBMSs to track transactions that match or exceed anything Facebook and Twitter are doing. I guarantee you, without a single doubt in my mind, that Facebook and Twitter could be run on a SQL RDBMS ... by that I mean Oracle, not MySQL.

Some people just want the holy grail (2, Insightful)

SmallFurryCreature (593017) | about 4 years ago | (#31647886)

I think some developers keep looking for the holy grail. Some magical solution that will turn development from punching in code, to Star Trek: "Computer do my job for me please".

Template languages, 4GL, NoSQL, Ruby on Rails... it is all part of an attempt to take the nasty out of development and they all... well... they all just don't really happen.

Because deep down, with all the frameworks and generators, if you want your code to do what you want it to do, you are still writing out if statements a lot.

And yes, OO and such also belong to this. Not the concept themselves, but the way most people talk about. OO means code re-use right?

If you said yes, then you are a manager, go put on your tie, you will never be any good at coding.

You can re-use all code. And it has been done for a long time.

What, did you think that people who wrote basic for the C64 went "Oh I wrote this bit of code for printing, now I need the same functionality, I am going to write it all over again!"

OO does make code re-use a bit easier BUT that is NOT the claim that people often make. Trust me, I ask this in interviews and it is always the same answer. Apparently you can't re-use functions. No way, no how. NEXT!

I see two kind of developers. Those who hate their job and those who don't. The former want to be managers, get away from writing code as fast as possible. And they will leap on anything that seems to make their jobs easier. Meanwhile the rest of us go on with actually producing stuff.

Just check, how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you don't need to write another line of code ever!

Re:Some people just want the holy grail (1)

WrongSizeGlass (838941) | about 4 years ago | (#31647946)

"Computer do my job for me please"

[HAL] Certainly, Small Furry Creature ... would you like fries with that? [/HAL]

Re:Some people just want the holy grail (3, Insightful)

Vellmont (569020) | about 4 years ago | (#31648068)

In some ways I agree with the general idea of your post. But stepping back a bit, code HAS gotten easier to write over the long term. I'd hope nobody would argue that writing a large application in a modern high level language is easier than writing it using 1970s technology in assembly. Those advancements in language came through a lot of trial and error (a lot of error). How many failed language exist that turned out to be dead ends (though spurred further advancements and refinements?). How do you know the technologies you mentioned won't turn into the next (your favorite productive language here)?

You're right that endlessly pursuing the latest trend is just foolhardy, as most "new latest greatest technology" turn out to be duds. The point being those duds sometimes DO pan out. Anyone that thinks that relational databases are the end-all-be-all of persistent data storage hasn't done enough relational database development to understand some of the limitations.

Re:Some people just want the holy grail (1, Informative)

tukang (1209392) | about 4 years ago | (#31648070)

OO does make code re-use a bit easier BUT that is NOT the claim that people often make. Trust me, I ask this in interviews and it is always the same answer. Apparently you can't re-use functions. No way, no how. NEXT!

You can reuse functions but you can't extend them and that's where OOs reuse shines. It's very powerful to be able to lay out your code as a tree and control the reuse 'flow' at the nodes.

Re:Some people just want the holy grail (1)

raftpeople (844215) | about 4 years ago | (#31648330)

But, in defense of the parent, when OO was first becoming popular on a large scale (early 90's), that was exactly the message in the media etc. OO will make programming a snap because you just plug together a bunch of objects.

The reality is that OO's primary benefit is in reducing complexity by encapsulation, although for some specific areas like GUI's it has the additional benefit of easy extension.

Re:Some people just want the holy grail (0)

Anonymous Coward | about 4 years ago | (#31648126)

And yes, OO and such also belong to this. Not the concept themselves, but the way most people talk about. OO means code re-use right?

If you said yes, then you are a manager, go put on your tie, you will never be any good at coding.

Don't get so high and mighty. The answer to "OO means code re-use right?" is "Yes." This answer in no way implies that it's the only means of code re-use; you probably meant your sarcastic hypothetical to mean "Re-use means OO, right?"

Re:Some people just want the holy grail (1)

SanityInAnarchy (655584) | about 4 years ago | (#31648304)

I think some developers keep looking for the holy grail. Some magical solution that will turn development from punching in code, to Star Trek: "Computer do my job for me please".

While true, that doesn't invalidate actual progress.

deep down, with all the frameworks and generators, if you want your code to do what you want it to do, you are still writing out if statements a lot.

Sure, no one claimed otherwise. The point is that I'd much rather be writing the if statements that have something to do with what I want my code to do, rather than the if statements that have to do with how to manage a session, or how to handle one URL vs another, or how to sanitize this particular query for the database.

As an example, you bash Rails -- ActiveRecord is hardly the only ORM capable of this, but it's possible to build a Rails app without writing a single line of SQL, or opening yourself up to a hint of a possibility of a SQL injection attack. Similarly, writing in any language higher-level than, say, C or C++, will generally save you from the possibility of a buffer overrun.

Now, is that going to take out all the tedium? No, it might not even make my job less tedious at all. What it will do is mean I'm more productive -- I'm doing more in the same amount of time. That's usually valuable.

yes, OO and such also belong to this. Not the concept themselves, but the way most people talk about. OO means code re-use right?

It's a way of organizing your program, and it actually does have a lot to do with code re-use. For example:

Apparently you can't re-use functions. No way, no how. NEXT!

One core goal of OO is to encapsulate and hide away the details of a given concept and expose only a simple, re-usable interface. Now, anything you can do in one Turing-complete language, you can do in another, but it can be a considerably different level of pain and complexity. Consider basic patterns like iterators in a language like C -- yes, you can do them, but does it really make sense?

Just check, how many times do you get one of those managers wannabe introducing something they read in a magazine because it promises that you don't need to write another line of code ever!

Well, I tend to advocate Rails, web apps, NoSQL, REST, higher-level languages, metaprogramming, and so on. I do this partly because of what I can do with those, and partly because they make my job easier, and thus more productive.

I never do them because I expect to stop having to write code.

Walmart's primary business isn't online (0)

Anonymous Coward | about 4 years ago | (#31647896)

Walmart's primary business isn't online. No comparison.

Right Tools For The Job (1)

Ashcrow (469400) | about 4 years ago | (#31647902)

I think the frustration is actually in some people not using the right tools for the job. I like NoSQL databases (specifically MongoDB), but I have not used them with anything I've written. Why? Because it wasn't the right tool for the job. I tend to use MySQL, Postgres or sqlite because it's so widely available and well known in how to administer. There are times that NoSQL will makes sense, it's just not the area I work in.

I do think we are going to continue seeing an uptick in NoSQL related things since many companies are fixated on "the cloud" while not really knowing what "the cloud" is (heck, no one still really, truly has a common definition of what it means ...). Since NoSQL seems to be a popular tool, and "the cloud" is a popular buzz phrase CIO's/CTO's will likely be pushing their shops to utilize "NoSQL in the cloud". While large scale applications which don't require relational information and need fast syncing across many servers is good grounds for NoSQL, these "NoSQL in the cloud" instances will probably not actually fit that status.

I do agree that it will be a good thing when "NoSQL for everything" dies. Just like it was a good thing when "PERL for everything", "Java for everything" and "Ruby for everything" died, but let's not throw out the whole idea because a lot of people use it wrong.

XML (of databases)? (1)

Manip (656104) | about 4 years ago | (#31647906)

The company I work out is currently having a huge headache moving from files into databases. We currently store everything in XML which gives us a great amount of freedom and adaptability. However most database solutions fix you to a single (or handful) of data definitions. Which you can kind of re-create XML be defining all kinds of crazy relationships, it gets hugely convoluted (to say the least).

I would LOVE to see a document/XML-live database. Just needs to do things that standard databases support (e.g. Security Model, Easy Mirroring, Search/Queries) to make it worth our while moving at all. Last I checked we're up to 260,000 XML files and approx 40 different distinct file "formats" (XML layouts).

Re:XML (of databases)? (1)

DalDei (1032670) | about 4 years ago | (#31647994)

You want MarkLogic (www,marklogic.com). Really, you do. You'll never go back to Relational again. /Disclaimer ( I'm not related to MarkLogic, just a fanboy)

Re:XML (of databases)? (1)

Gorath99 (746654) | about 4 years ago | (#31648078)

Have you checked out something like XML DB [oracle.com]? I haven't used it much myself, but it sounds like it may meet your needs. It comes bundled with the XE database [oracle.com], which is free as in beer. (But XE has some limitations that the enterprise product doesn't have, of course.)

Disclaimer: I work for Oracle.

Re:XML (of databases)? (1)

kronosopher (1531873) | about 4 years ago | (#31648196)

use an object relational mapper or something similar to generate interoperable database/xml schematics.. you should be able to write conversion scripts pretty easily that way. In so far as mirroring and xml and sql datastores, I'm not sure if such a solution exists.

Re:XML (of databases)? (1)

kuhneng (241514) | about 4 years ago | (#31648248)

Oracle and DB2 both support the SQL/XML standard and provide quite a bit of functionality for native handling of XML. Both can store structured / compressed representations in a native XML type (with or without a predefined schema) and use XPath-based indexes for efficient query execution.

Wonderful stuff, and one of the few features I really miss back in the PostgreSQL world.

because all apps are the same (1)

vonkohorn (688787) | about 4 years ago | (#31647940)

So they should all use the same data management tools as wallmart. Is that the reasoning? Better to use the right tool for each job. Some things work better in a nosql non-schema.

Agree with other posters (1)

daveb1 (1678608) | about 4 years ago | (#31647942)

Agree with other posters. sql is a tool. The point about nosql is that is is a different tool. ACID in a database is fine normally. However, if you can live without it, which many can, do so!

SQL (0)

Anonymous Coward | about 4 years ago | (#31648008)

I don't like SQL, but I do like relational databases. If only someone would come up with a relational query language with nice, non-COBOL-esque syntax (maybe lispy...) that just did much the same thing as SQL, and add it to a powerful RDBMS engine like postgresql's or something. (Yes, I'm aware of the history, and that SQL was added to postgres which followed on from ingres which used a non-sql relational language that was somewhat nicer than SQL... oh, the ironing...)

The NoSQL debate never gives any real information (1)

i_ate_god (899684) | about 4 years ago | (#31648020)

At first, I thought NoSQL like Cassandra should simply be used as a store for precomputed relationships. Then I thought NoSQL was just a structureless store that can scale in any given direction with no effort.

Both sound interesting, but then the debate against NoSQL is just "well, SQL can already do all that, but you get data integrity with it. If it doesn't scale, then just build a manly man's server and it will".

So, I dunno. The whole debate has gotten very religious very quickly and as a result, no one is really doing a proper comparison because no one seems to take the approach of "right tool for the right job, so here are the jobs NoSQL Is right for, and here are the jobs your RDBMS is good for".

More RDBMS dogma (3, Insightful)

Angst Badger (8636) | about 4 years ago | (#31648048)

Use the right tool for the job, except databases, eh?

The simple fact of the matter is that not every app is aiming for Google's scale. (Not every app is web-based or even going to be web-based, though people seem to forget that.) And even some large-scale apps don't fit the relational model very well, medical records being one of the more outstanding examples.

And yes, I have read Codd and Date and understand the relational model and its benefits very well, and it annoys me to no end when people break the relational model without realizing or understanding what it costs them. That said, sometimes those costs are acceptable, and sometimes an application requires features that the relational model does not (and in fact cannot) bring to the table.

It may be, as with every other silver bullet fad, that what's at work here is the basic human tendency to become familiar with something, begin to see everything in terms of it, and then try to persuade anyone who'll listen that they are in possession of the all-singing, all-dancing solution to all problems. Today, it's Ruby, multi-touch interfaces, and functional programming. But not very long ago it was COBOL and CICS. And while one must acknowledge that progress has been made, it is equally obvious that progress will continue to be made and that "one size fits all" is always BS, even in clothing.

"It's Just a damned popularity with you kids!" (1)

Dark_Matter88 (1150591) | about 4 years ago | (#31648120)

Sure, Ive messed around with some NoSQL databases, they just aren't my thing, give me mysql, your spec and a cup of tea and i dont have to look round silly experiments to see the best way of doing things in new radical 'paradigms.' That being said, I am glad the experiments are being done by people who are in such an environment to experiment. I mean, like the article says, its the social networks like twitter and facebook developing things like Cassandra, and its good that there is someone pushing the bar, but they are the only people who CAN do this, they aren't necessary, nobodies gonna die from a 5 minute outtage of poking each other (that sounds bad). I havent really understood the whole NoSQL thing,I havent really ever had a problem with SQL based Databases, maybe thats just the nature of my work, but it all seems as though this has nothing to do with technology, just people who want to be heard...

Price may favor noSQL for some applications (4, Informative)

cervo (626632) | about 4 years ago | (#31648134)

Many of the NoSQL sources scale better than a normal database and are available cheap. Oracle costs a fortune, and if you want to run Oracle on a cluster good luck. They also don't let you publish benchmarks without their permission. But most people I know who use Oracle claim it totally beats everything else (without further clarification). DB2 includes a cluster edition that is also quite good. It uses a shared nothing architecture. But none of these solutions are free. Also teradata is also cited as a good parallel database. If you are a start-up and your choice is a NoSQL solution that is almost free or 100,000+ for some commercial parallel database, which do you go to?

But no matter what you will consume resources with a relationship database on ensuring consistency (which many times is what you want but not 100% of the time). Amazon's Dynamo works by not caring so much about consistency and trading consistency for availability of the overall service. For a shopping cart it is fine, but you wouldn't want to do your credit card processing using it. Google's GFS is optimized to do the file operations that google does the most. However there was an article in the ACM not that long ago comparing Map Reduce (Hadoop's implementation) against two parallel databases, and it lost. OF course the Parallel Databases were all not free....and hadoop is....

So overall I'd say the decision comes down to price mostly (as it does with most startups). If you can make do with one server than sure do PostgreSQL (or mySQL...although they always tried to force licensing for commercial products even though it is GPL...). If you need a cluster, both have clustering solutions, but as far as I can tell they are not as good as the commercial Parallel databases. If you have lots of money then sure go with Oracle, it seems through word of mouth Oracle is the best for both parallel and stand alone in terms of performance. DB2 was good enough for a former job. They had terabytes in the mid 1990's using about 20 servers. Now that the hardware is much better I'm sure it scales even better.... But if money is a consideration, then go with an open source noSQL solution. A lot of people now swear by Cassandra, I haven't had a chance to check it out yet.

Other reasons for not using a relational database (0)

Anonymous Coward | about 4 years ago | (#31648190)

For me, it's not about scalability at all; I simply don't see a relational database as very good at reflecting the organisation of the data I want to store. For some data sets, it might fit perfectly, but it is usually a far-fetched way to represent the data, in my opinion.

I'm Still Fuzzy on NoSQL (4, Interesting)

RAMMS+EIN (578166) | about 4 years ago | (#31648234)

I'm still fuzzy on what NoSQL is supposed to be and what it is supposed to bring to the table.

From what I've understood, it's basically a common banner for various different databases that all share the common property of not being relational databases and not providing ACID guarantees.

If so, it seems to me that the whole NoSQL vs. RDMBS [wikipedia.org] debate is about a false dichotomy. There are some applications where a relational database is the right tool for the job, and there are some where a relational database is not the right tool for the job. In some of those latter cases, one of the NoSQL databases may be the right thing.

This is nothing new. Non-relational databases have been used on Unix for a long time, and are even a standard part of POSIX (see for example the manpage for dbm_open [opengroup.org]). It's also long been known that, for example, Berkeley DB [oracle.com] can be a lot faster than an RDBMS - as long as your application doesn't make use of all the features an RDBMS provides. Lots of programs even don't use one of these database systems, but invent their own, custom format. Git [git-scm.com] is a very successful example of this.

To me, it seems that what we are seeing here is loads of people who had learned to use relational databases for all their storage needs discovering that there are other ways to store data, and that one of those methods may work better than an RDMBS for a particular application. Well, yes. Does that surprise anyone? It sure doesn't surprise me. Does it mean that RDMBSes are now useless? Not at all. Does it mean you should use a non-relational storage system where this makes more sense? Of course! Now, can we please get back to work? I don't see the point of having a holy war over whether RDBMS or NoSQL is better, when common sense says that they both have their uses.

BS (1)

ajung (116367) | about 4 years ago | (#31648294)

I call: bullshit

We are using object-oriented databases like the ZODB for ten years when the data model is not relational oriented
We are using relational databases when your data is relational
We are using relational databases and object-oriented databases together in the same app when we need both
We are not using MySQL when we are in need of a *real* database.

Use the right tool for each problem - only idiots use a RDBMS for all and everything.

I'm NOT? (0)

Anonymous Coward | about 4 years ago | (#31648302)

From the article:

You Are Not Google

Really? My paystub says otherwise, you ignorant clod!

SQL performance (3, Insightful)

garry_g (106621) | about 4 years ago | (#31648306)

People complaining about SQL performance are most likely either using incorrectly scaled machines for the job, or believe they can throw a four-line SQL statement at the database and expect it to work out the optimization on its own ... query optimizers may be able to do a decent job on average, but once you go large databases (multi-million dataset tables), planing the query structure will go a long way preserving performance.
Yes one can write complicated queries to return exactly what you want in one query, but in many cases doing some logic around it and using smart grouping/loops will outperform the complex query ...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...