>>>>>>>> I see few instances with my applications can’t benefit from a SQL Database>>>>>>>>>>>>>>>>>>>>>>

Distributed heterogeneous database computing :)

Not that I use it much, but why no mention of MySQL?

SQLite I have a soft spot since it is very portable and scales well, SQL Compact is buggy and slow however. However, SQL engines are highly optimized and things like LINQ to XML are terribly slow on a Windows Mobile device when you are using the .NET CF Framework.

XPath / XQuery is limited in power as well, and typically I stick with SQL because then I have adopted a framework that I know will limit my power later on when more complex features are put in by the product owner.

Point being, SQLite is so damn easy to implement since there are open source Linq to SQLite Providers that you might as well start off with a "lite" tool but you know will scale well.

Probably because no one else is using it either. Not that I am at the top of the game, but it seems like people only use that stuff to "flex their muscles". Out in "the real world" people use the proven mainstream stuff. But I think he's really talking about sending a query to a database rather than using some other interface.

To the OP, I do a lot of prototyping, and since I'm always under one time constraint or another, and have little time to flex my muscles or to even TRY to flex my muscles, I use SQL for most things. Though I will say that the acrobatic stuff you can do with LINQ is cool, and I like to use it when I can do so without stepping on toes.

I guess it depends on the complexity of the application. I postulate that most stand-alone desktop apps have no need for SQL Server or any of it's free or nearly free counterparts. In these cases LINQ to XML likely has all the power you need and avoids dependency on a database server.

Hey Joe,

I agree that using SQL for every data solution can be overkill, especially with all the great things that you can get through caching and Linq to XML. However, I don't think that it is plausible to eliminate an RDBMS altogether.

If NoSQL causes the industry to rethink the traditional approach to data storage and management, then more power to them.

But, we should be mindful not to throw the baby out with the bath water.

Thanks,

BD

Forgive my ignorance (I'm a .NET newbie), but if it's a desktop solution rather than sitting on a server, why not simply serialize your objects and save them. Wouldn't that be faster than converting everything to/from XML?

I know the article points out some big names and a few examples, but picking out a red and green M&M from the bag doesn't make it Christmas time. I don't think the fact that because Google has specialize needs and a different tool to solve means they are good poster child for a "movement". Really, how many Googles are there?

I have worked with several developers who never vary from the cookbook. A cup of flour, pinch of salt, a dash of RDBMS and a heaping scoop of web forms: all done. They never even consider other options, mindlessly tackling the problem at hand. Ultimately I think root of No SQL is a rebellion against mindless development.

Now I know that everything looks like a nail when you have a hammer, but sometimes you really want to use that screw driver. A rebellion against hammers, however, means that you start breaking out the screwdrivers, measuring tape and welding torch... which is all find and dandy until you actually come across a nail.

I think you nailed it on the head when you suggest that needs vary, and accordingly technology to service those needs vary. I think complete avoidance of a relational database is silly; there is a domain of tasks that databases handle really well, and any develop who would avoid using one for the sake of avoidance is (imo) one that needs to take another look at the Sales jobs they just passed up. At the same time, if the benefits do not outweigh the costs for your particular situation then it is a bad fit and move on (don't use a hammer for a push-pin).

I read the article, seems they missed a fairly solid player in the "NoSQL" area, CouchDB.

Working with scalability problems in legacy RDBMS's, I cannot see customers migrating to data stores as I highlight here: bigdatamatters.com/.../nosql-vs-rdbms.