mike.mainguy

Anybody not living in a cave knows that NOSQL is a current hot topic amount technology solutions. One sadly missing piece is some sort of guide on how to determine if NOSQL or a more traditional RDBMS is a better solution. To start with, I'll say you should assume that an RDBMS is probably the safest bet. Almost anything you can do with a document store can be done with an RDBMS, with the exception that it may not scale and/or perform as well as NOSQL solution. The big advantages of RDBMS solutions is that they have an enormous ecosystem of tools, documentation, and skilled administrators. Given the above, why would anyone ever even look at a NOSQL solution? Here are a couple indicators that a NOSQL solution might be a better fit for your problem: #1 You are storing simple key/value pairs. If your RDBMS "solution" ends up being a single table with a couple key fields and a CLOB with XML in it... you're probably using the wrong tool for the job. #2 You a...

I've been investigating methods of storing content online and ran across an interesting offering from cloudant . They offer a 2gb couchdb database for free. For folks who don't know, couchdb is a json/RESTful distributed document database. If you're trying to manage online content for a web application it has some interesting advantages over the competition. The most interesting advantages to me are: Native RESTful javascript/JSON API. The database itself uses http as the communication protocol Inherent MVCC support. This means old versions of a document live after they've been updated Built-in searching and materialized views. I can define some metadata about my content and instantly retrieve it Some of the competition in this case would be: Mongodb Amazon S3 While it turns out that S3 and MongoHQ both have free offerings, the online console at cloudant is the most user-friendly (as of this second).

I read with interest an article about the mentality behind nosql nosql-vs-rdbms-let-the-flames-begin.html . From my perspective, this debate isn't really a debate and I've written about similar things before. If you stop for a moment and think, it seems obvious that giving up a relational model and giving up ACID compliance reduces overhead. It should also be obvious that you are giving up things that many people for many years have thought are really important. To a person selecting an underlying database implementation, part of your decision making process needs to take these things into account. Here's a quick list of things to consider: How important is speed? (how long can we wait for one operation to finish) How important is scaleability? (how many operations must we be able to do at one time) How much money can I spend? (Can I spend a $200,000 on a honking server?) Who is going to support this system? (A bunch of developers, a bunch of dbas, or both?) How big...